Недавно побывал в Киеве на конференции ReqLabs, посвященной деятельности бизнес-аналитиков. Основная аудитория слушателей — Project manager'ы, Team Leader'ы, бизнес / системные аналитики, одним словом люди, занимающие руководящие должности в своих компаниях.
В целом понравилось: много толковых идей, интересных докладов, равно как и самих докладчиков. Последние тоже весьма высокого уровня: от штатных бизнес/системных аналитиков до руководителей компаний.
Конференция проводилась на базе учебного центра московской компании Luxoft (хотя у неё, как я понял, много офисов разбросано по всему миру). В плане организации самого мероприятия всё было на хорошем уровне: помещения, мебель, обеды, закуски и т.д. Взял на заметку: организация таких мероприятий — неплохой способ пропиарить компанию:
Основные идеи и просто интересные мысли в докладах, которые запомнились:
Запомнилась эта фраза, в которой в общем-то нет ничего нового, но которая, тем не менее, порой бывает актуальна, когда, не подумав, начинаешь что-то «улучшать» на проекте.
Очень интересно было сказано про методологию компании IBM RUP: «RUP — это поваренная книга. Вы её открываете, когда хотите узнать решение той или иной проблемы, причём вам будет предоставлена чёткая последовательность действий, как именно проблему решить. Как только вы её решаете, можно книгу закрывать».
Идея здесь следующая: в любой компании так или иначе есть вертикаль вида «руководство/топ-менеджмент — менеджеры — низшие звенья». Так вот очень важно, чтобы от «низших звеньев» поступал какой-то фидбек наверх о различного рода проблемах и недочётах. Причём аккумулировать мнения должны менеджеры на местах и передавать их наверх, чтобы они дошли до руководства.
Это, надо сказать, актуально, т.к. бывает, что люди «внизу» боятся говорить о плохих вещах вышестоящим менеджерам, что в общем-то объяснимо: никто не хочет приносить плохие известия :)
Если фидбек не поступает, может возникнуть ситуация, когда топ-менеджмент живёт в отдельной реальности, полагая, что всё окей и никаких проблем нет.
«Провалы и неудачи при решении различных задач вызваны, в первую очередь, ошибками топ-менеджмента, который неправильно поставил процесс. Это — 90% случаев. И только в остальных 10% случаев виноваты обычные работники, которые что-то сделали не по инструкции / регламенту».
С этой фразой согласен, чаще всего так и бывает. Если ты занимаешь какую-то руководящую позицию, нужно в первую очередь спрашивать себя, что было сделано не так.
Очень важно замотивировать всех участников команды, чтобы повысить её КПД. Это можно сделать разными способами:
а) Высокой зарплатой, как показателем ценности человека.
б) Обещаниями карьерного роста (позиция в компании / зарплата).
в) Обещанием предоставить долю в проекте по факту его запуска (вероятно, больше актуально для стартапов с небольшой командой).
Здесь были подняты актуальные вопросы:
1. Как и в чём оценивать качество?
2. Как его повысить?
Основная мысль: контроль качества должен происходить по мере самого производства тем лицом, которое что-то делает. Это эффективнее, чем приставлять надсмотрщика, который будет контролировать исполнителя, ведь самого надсмотрщика никто не будет контролировать, и он также может ошибиться. Конечно, на эту тему можно подискутировать, но доля истины здесь есть. Достичь этого можно, как мне кажется, если хорошо замотивировать человека (см п1.4), ну и конечно уровень профессионализма должен быть соответствующий.
Команды без явного лидера, вроде бы решают задачи эффективнее, чем традиционные команды с ярко выраженной структурой (лидер — исполнители). Но здесь, как мне кажется, не всё гладко. В первую очередь, чтобы такая команда состоялась, профессионализм каждого из её учатсников должен быть достаточно высоким.
Было озвучено такое мнение, что «если в команде есть слабое звено, которое снижает её (команды) эффективность, то проще это звено выкинуть, чем проводить какие-то оптимизации внутри самой команды». Вероятно, собрать такую команду нелегко.
Смысл приблизительно таков, что есть разные типы задач:
а) Конкретные технические задачи, поставленные менеджером.
б) Ресёрчинговые задачи (нечёткие), в которых нужно проявить творчество и которые явно не поставлены менеджером.
Считается, что задачи второго типа решаются человеком эффективнее в силу того, что он может здесь проявить некоторый полёт фантазии и больше творчества.
Тут, наверное, можно провести некоторую аналогию с работой на себя (бизнес, фриланс и т.д.) и с работой «на дядю». Мысль «работать на себя», думаю, каждому приятнее :)
Понравилось про принцип вовлечения стейкхолдеров (заинтересованных лиц) в проект. Основная идея: перед началом работы над любым проектом необходимо определить перечень всех стейкхолдеров (заинтересованных лиц), которые могут хоть как-то оказывать влияние на проект. Далее этих людей нужно перенести на квадрат следующего вида:
Люди, которым проект очень интересен, но которые не принимают ключевых решений на проекте.
Лица, принимающие решения (ЛПР), которые активно работают на проекте.
Люди, которых надо держать «на прицеле», т.к. с одной стороны они являются ЛПР, с другой — не проявляют сильного интереса к проекту. Вы, наверное, сталкивались с ситуацией, когда делаете проект, всё окей, а затем внезапно приходит некто (директор или какой-нибудь top-менеджер) и говорит: «Всё, что вы тут сделали — фигня, делать нужно было не так». И понеслась :)
Как раз чтобы такого не было, людей из 3го квадрата нужно по-максимуму вовлекать в проект, повышая их интерес.
Люди, которых нужно просто «мониторить», т.к. сегодня они в 4м квадрате, а завтра переместятся в другой, и это нужно вовремя отследить и учесть.
При такой формализации становится сразу понятно, кто и какую позицию занимает на проекте.
Из интересных докладчиков стоит отметить Пауля Тернера: «The Evolving role of the Business Analyst», Адриана Рида: «Stakeholder Engagement: Delivering projects in the face of adversity», Михаила Кумскова: «Процессы и люди» и Петра Лободу/Елену Голубенко: «Бизнес-анализ в сфере телекоммуникаций». Эти докладчики были одними из лучших, правда британские докладчики на фоне своих украинских «коллег» мне понравились больше: лучше предпоносили информацию слушателям, доклады были очень хорошо проработаны.
PS. На конференции было ещё много всего интересного, но, к сожалению, в одной статье всего не охватишь, я выделил лишь самые интересные, на мой взгляд, моменты. Буду рад ответить на вопросы.
В целом понравилось: много толковых идей, интересных докладов, равно как и самих докладчиков. Последние тоже весьма высокого уровня: от штатных бизнес/системных аналитиков до руководителей компаний.
Конференция проводилась на базе учебного центра московской компании Luxoft (хотя у неё, как я понял, много офисов разбросано по всему миру). В плане организации самого мероприятия всё было на хорошем уровне: помещения, мебель, обеды, закуски и т.д. Взял на заметку: организация таких мероприятий — неплохой способ пропиарить компанию:
- Можно собрать большую базу резюме и потенциальных работников.
- О компании лучше будут знать в стране, т.к. участники — не только киевляне и не только рядовые IT'шники, но и менеджеры / руководители.
- О компании смогут узнать за границей, т.к. докладчики — не только из Украины.
Основные идеи и просто интересные мысли в докладах, которые запомнились:
Прежде чем решать проблему, необходимо её обозначить
Запомнилась эта фраза, в которой в общем-то нет ничего нового, но которая, тем не менее, порой бывает актуальна, когда, не подумав, начинаешь что-то «улучшать» на проекте.
Очень интересно было сказано про методологию компании IBM RUP: «RUP — это поваренная книга. Вы её открываете, когда хотите узнать решение той или иной проблемы, причём вам будет предоставлена чёткая последовательность действий, как именно проблему решить. Как только вы её решаете, можно книгу закрывать».
Компании, основанные на страхе — неэффективны
Идея здесь следующая: в любой компании так или иначе есть вертикаль вида «руководство/топ-менеджмент — менеджеры — низшие звенья». Так вот очень важно, чтобы от «низших звеньев» поступал какой-то фидбек наверх о различного рода проблемах и недочётах. Причём аккумулировать мнения должны менеджеры на местах и передавать их наверх, чтобы они дошли до руководства.
Это, надо сказать, актуально, т.к. бывает, что люди «внизу» боятся говорить о плохих вещах вышестоящим менеджерам, что в общем-то объяснимо: никто не хочет приносить плохие известия :)
Если фидбек не поступает, может возникнуть ситуация, когда топ-менеджмент живёт в отдельной реальности, полагая, что всё окей и никаких проблем нет.
О неудачах в компании
«Провалы и неудачи при решении различных задач вызваны, в первую очередь, ошибками топ-менеджмента, который неправильно поставил процесс. Это — 90% случаев. И только в остальных 10% случаев виноваты обычные работники, которые что-то сделали не по инструкции / регламенту».
С этой фразой согласен, чаще всего так и бывает. Если ты занимаешь какую-то руководящую позицию, нужно в первую очередь спрашивать себя, что было сделано не так.
О мотивации команды
Очень важно замотивировать всех участников команды, чтобы повысить её КПД. Это можно сделать разными способами:
а) Высокой зарплатой, как показателем ценности человека.
б) Обещаниями карьерного роста (позиция в компании / зарплата).
в) Обещанием предоставить долю в проекте по факту его запуска (вероятно, больше актуально для стартапов с небольшой командой).
О контроле качества
Здесь были подняты актуальные вопросы:
1. Как и в чём оценивать качество?
2. Как его повысить?
Основная мысль: контроль качества должен происходить по мере самого производства тем лицом, которое что-то делает. Это эффективнее, чем приставлять надсмотрщика, который будет контролировать исполнителя, ведь самого надсмотрщика никто не будет контролировать, и он также может ошибиться. Конечно, на эту тему можно подискутировать, но доля истины здесь есть. Достичь этого можно, как мне кажется, если хорошо замотивировать человека (см п1.4), ну и конечно уровень профессионализма должен быть соответствующий.
Самоорганизующиеся команды
Команды без явного лидера, вроде бы решают задачи эффективнее, чем традиционные команды с ярко выраженной структурой (лидер — исполнители). Но здесь, как мне кажется, не всё гладко. В первую очередь, чтобы такая команда состоялась, профессионализм каждого из её учатсников должен быть достаточно высоким.
Было озвучено такое мнение, что «если в команде есть слабое звено, которое снижает её (команды) эффективность, то проще это звено выкинуть, чем проводить какие-то оптимизации внутри самой команды». Вероятно, собрать такую команду нелегко.
Задачи, не поставленные явным образом, выполняются с большим энтузиазмом
Смысл приблизительно таков, что есть разные типы задач:
а) Конкретные технические задачи, поставленные менеджером.
б) Ресёрчинговые задачи (нечёткие), в которых нужно проявить творчество и которые явно не поставлены менеджером.
Считается, что задачи второго типа решаются человеком эффективнее в силу того, что он может здесь проявить некоторый полёт фантазии и больше творчества.
Тут, наверное, можно провести некоторую аналогию с работой на себя (бизнес, фриланс и т.д.) и с работой «на дядю». Мысль «работать на себя», думаю, каждому приятнее :)
Вовлечение заинтересованных лиц в проект
Понравилось про принцип вовлечения стейкхолдеров (заинтересованных лиц) в проект. Основная идея: перед началом работы над любым проектом необходимо определить перечень всех стейкхолдеров (заинтересованных лиц), которые могут хоть как-то оказывать влияние на проект. Далее этих людей нужно перенести на квадрат следующего вида:
1я четверть
Люди, которым проект очень интересен, но которые не принимают ключевых решений на проекте.
2я четверть
Лица, принимающие решения (ЛПР), которые активно работают на проекте.
3я четверть
Люди, которых надо держать «на прицеле», т.к. с одной стороны они являются ЛПР, с другой — не проявляют сильного интереса к проекту. Вы, наверное, сталкивались с ситуацией, когда делаете проект, всё окей, а затем внезапно приходит некто (директор или какой-нибудь top-менеджер) и говорит: «Всё, что вы тут сделали — фигня, делать нужно было не так». И понеслась :)
Как раз чтобы такого не было, людей из 3го квадрата нужно по-максимуму вовлекать в проект, повышая их интерес.
4я четверть
Люди, которых нужно просто «мониторить», т.к. сегодня они в 4м квадрате, а завтра переместятся в другой, и это нужно вовремя отследить и учесть.
При такой формализации становится сразу понятно, кто и какую позицию занимает на проекте.
Из интересных докладчиков стоит отметить Пауля Тернера: «The Evolving role of the Business Analyst», Адриана Рида: «Stakeholder Engagement: Delivering projects in the face of adversity», Михаила Кумскова: «Процессы и люди» и Петра Лободу/Елену Голубенко: «Бизнес-анализ в сфере телекоммуникаций». Эти докладчики были одними из лучших, правда британские докладчики на фоне своих украинских «коллег» мне понравились больше: лучше предпоносили информацию слушателям, доклады были очень хорошо проработаны.
PS. На конференции было ещё много всего интересного, но, к сожалению, в одной статье всего не охватишь, я выделил лишь самые интересные, на мой взгляд, моменты. Буду рад ответить на вопросы.
