Есть план

Техническое задание. Кто его должен писать?

Konstantin Bychenkov — Sat, 11 Feb 2012 19:58:19 +0000

На одной из встреч нашего “Самарского профсоюза менеджеров проектов” мы вскользь рассмотрели вопрос – кто должен писать ТЗ на проект? Вы – менеджер проекта в “мааааленькой компании”, у которой персонал малым количеством выполняет много разных ролей.Приходит к вам заказчик (тоже – “мааааленький”) и просит написать техническое задание на проект, который ему нужен. Вы его пошлете писать ТЗ самостоятельно или возьметесь? “Все зависит от суммы” – скажете вы и будете правы, как бизнесмен. Ну, давайте считать, что заказчик готов платить сумму, которая вам нужна. Тогда как? Вопрос, достаточно распространенный, например, было такое обсуждение на Linux.org

Что отличает “хорошее ТЗ” от “плохого ТЗ”? То, что в хорошем задании достижение бизнес-целей ясно и исчерпывающе отражается в видах запланированных работ. Поэтому часто исполнители не любят писать ТЗ за некомпетентного в IT заказчика. Надо и цели выяснить и работы под них подогнать. Так как исполнитель в бизнесе заказчика как правило ничего не понимает, то в этом случае они берут на себя большие риски. Разработка ТЗ превращается в “challenge task”.

Фирма, разрабатывающая софт на заказ заинтересована сделать как можно больше проектов в кратчайшие сроки. Маленькая фирма всегда борется за выживание, пара невыгодных проектов вполне может подорвать бизнес. Тут уже не до того чтоб сделать все как надо. Было бы выполнено задание и подписаны акты выполненных работ. Не все проекты входят в портфолио на сайте, не все проекты оказывают существенное влияние на репутацию исполнителя.

Большинство заказчиков эту ситуацию читают. Поэтому на первом этапе настаивают на том, чтобы исполнитель сам писал техническое задание. При этом заказчик надеется, что исполнителю придется в итоге вскрыть больше задач и рисков в процессе работы над документом, потому что “ну вы же профессионал, Петров” (с).

И по совести – заказчик тут прав. Потому что программный продукт нужен не ради себя самого, а ради достижения какой то цели.

Если же стороны все таки хотят договориться, то есть приемлемый для всех подход.

Заказчик пишет видение продукта:

Бизнес-цели – цели, которые преследует заказчик в данном проекте;
Аудитория продукта и характеристика объекта автоматизации
Описание основных сущностей и бизнес-процессов – необходимо для разработки структурной и функциональных моделей предметной области;
Желаемые этапы и сроки – контрольные точки с указанием промежуточных результатов, желательные для клиента.

Исполнитель по мотивам видения пишет эскизный проект или техническую концепцию, которая содержит в себе следующие части:

Модель ролей – какие социальные агенты и технические системы связаны с созданием данной с описанием их задач
Макет интерфейсов – требования к организации пользовательского интерфейса
Компонентная модель - состав, назначение и взаимосвязь технических компонентов системы;
Описание применения выбранных технологий – краткое описание инструментов реализации предложенной компонентной архитектуры;
Поэтапный план выполнения работ

Заказчик приходит к будущему исполнителю с видением продукта. На основе видения и предпроектного исследования исполнитель уточняет видение и пишет техническую концепцию. Это будет первым этапом работ по контракту. При таком подходе все отвечают за то, в чем действительно разбираются. Заказчик определяется со своими желаниями, исполнитель заранее говорит, как он будет добиваться успеха проекта.

А еще есть фирмы которые играют на упомянутых в этой статье рисках пишут за вас техническое задание. Но это уже другой случай.

Куплю мозг

Konstantin Bychenkov — Mon, 02 Jan 2012 15:59:00 +0000

или как нанять менеджера проектов

Когда-то я написал статью о том, что должен выяснить для себя соискатель, устраивающийся на вакансию менеджера проекта- «Абсолютный минимум для новой жизни». Но все меняется. В связи с расширением количества проектов начал подбирать кандидатуры менеджеров и взглянул на проблему «с другой стороны баррикады». Столкнулся сразу с двумя проблемками:

как сформулировать требования к кандидату?
как проверить соответствие кандидата требованиям?

С программистами все более-менее понятно: предложил тестовое задание, провел интервью на интересующие области знаний, прощупал личные качества и стремления — и принимай решение. Профессия программиста одна из самых «честных», навыки легко измерить.

Отрасль разработки ПО в России растет. По данным от 2009 года «последние 5 лет рост объема российского экспорта ПО и ИКТ-услуг составил в среднем более чем 40% в год, и в 2008 году данный объем экспорта превысил 2,6 млрд. долларов США» (взято с Материалы Минпромторга ictgov.ru) Растет и дефицит кадров, а скоро он усилится еще и тем, что на рынок труда выйдет немногочисленное «поколение 90х».

Все эти факторы приведут к тому (и это уже вовсю началось), что менеджеров перестанут выращивать внутри конторы, а начнут нанимать со стороны.

Как быть с менеджерами? У нас небольшая компания, но это не значит что у нас меньше задач, чем в компаниях побольше. Поэтому скорее всего нам не подойдет кандидат, который умеет делать хорошо только что то одно (управлять). Нужно чтобы он мог быть полезен еще в чем то — программирование, аналитика или еще что то.

Сложно придумать менеджеру тестовое задание, поэтому часто на собеседовании просто выясняют опыт кандидата. Или, в качестве задания задают вопрос, который должен вскрыть основную функцию, необходимую от кандидата. Но можно дать задание, которое позволит выяснить базовые навыки, необходимые для менеджера: как он умеет анализировать ситуацию, насколько хорошо знает предметную область, в которой предстоит работать, достаточно ли высоки его навыки устной и письменной речи. Поручите соискателю сделать небольшую презентацию на заданную тему, проанализировать сильные и слабые стороны какого-нибудь продукта. Рассказ о подвигах на предыдущих рабочих местах может быть интересен но, далеко не всегда характеризует истинные способности кандидата. Полезно выяснить, что кандидат знает о бизнесе вашей компании. Правильный соискатель обязательно предварительно соберет информацию о приглашающей компании.

Нанимая менеджера проекта, мы нанимаем руководителя. Причем как правило команда уже существует, мы просто хотим делегировать часть своих задач и полномочий. Ну с задачами еще понятно. Но, полномочия! Их можно делегировать только тому, у кого есть авторитет, кого «стая» признает “альфа-самцом«.Самое очевидное — глубокое знание технологий или предметной стороны вопроса. В первом случае это означает, что кандидат крут как программист. Тогда так ли уж ему нужны все эти хлопоты с управлением, если на фрилансе для Москвы и Питера он заработает больше? Другой вариант — способности и опыт аналитика. Умение вникнуть в предметную область , поставить задачу. Есть еще один «авторитетный» навык — это коммуникационные способности, которые трудно оценить формально, но которые видно в процессе личного общения. Чем крупнее проект, тем дальше на задний план уходят технические навыки и тем важнее становятся коммуникационные (политические) и аналитические способности.

При формировании вакансии опишите помимо формальных требований предметную область, которой предстоит заняться. Причем не просто одним словом — «электронная коммерция» или «мобильные сервисы», а конкретно, проект, с которого надо будет начать — «система торговли подержанными вещами» или «развитие мобильного приложения, которое позволяет выбрать оптимальный маршрут общественного транспорта в любом городе мира».

Всегда полезно узнать взгляд кандидата на роль менеджера проекта в организации. На то, какова должна быть структура фирмы и структура команды, в чем заключаются основные навыки и обязанности менеджера. Ваши взгляды на эту широкую профессию могут существенно различаться, что в перспективе может привести к конфликтам. Вообще, о правах и обязанностях надо договориться сразу и заранее. Хотя, не всегда это выгодно одной из сторон.

Попробовав по-разному, я все таки прихожу к выводу, что менеджер проектов должен работать на окладе. В качестве стимула можно рассмотреть бонусы по итогам завершения проекта, если все в срок и в бюджет.

Важны ли сертификаты и прочие дипломы, подтверждающие компетенции менеджера? С точки зрения подтверждения наличия знаний и возможности говорить на одном профессиональном языке — да. Но это вовсе не означает, что обладатель PMP не нуждается в поддержке в начале работы и что он все сам сможет. Дипломы не гарантируют результат.

В целом как правило хорошо справляются с работой менеджеров стабильные экстраверты. Хуже всего — невротичные интроверты. Было соответствующее исследование в Кембриджском университете. Так что следите за темпераментом соискателя.

Найм менеджера проекта — это всегда риск, потому что отдача от менеджера наступает позже, чем от разработчиков и аналитиков. Если вы в момент принятия решения не просто поняли, что нужен еще один «начальник», а точно понимаете, что будете ему делегировать, какого рода проекты он будет вести и как вы построите взаимодействие — риски будут минимальны.

Взаимоотношения сотрудник-фирма в предприятиях масштаба SME

Konstantin Bychenkov — Sat, 22 Oct 2011 16:55:59 +0000

В этом году я буду делать доклад на конференции «Разработка ПО 2011» CEE-SECR 2011

Немного о докладе.

Управление изменениями является одним из важнейших аспектов управления проектами и управления вообще. Но при этом часто забывают об изменениях, которые происходят с людьми. Часто мы забываем, что человек не все время один и тот же. Все люди меняются, в том числе и на работе. Вместе с ними меняются команды и коллективы предприятий. Перемены могут быть не всегда к лучшему. Ко переменам нужно быть готовым. Для успешной работы на всех уровнях нужно понимать закономерности и возможности на каждом этапе. Люди на разных уровнях ответственности часто не понимают друг друга. Их ожидания бывают противоположными. Это приводит к разочарованиям и в итоге, потере цели коллективом компании. Это удивительно, потому что фирма-то – маленькая, в ней по определению проще достичь понимания и устранить проблемы на ранней стадии.

Спектр SME компаний многообразен, в своем докладе я коснусь фирм, которые:

Ограниченны в возможности по привлечению ресурсов извне. Ресурсов просто на всех не хватает.
Росли «с нуля». Сначала появилась фирма – потом деньги.
Коллектив образовался как «рыцари круглого стола».

Мы рассмотрим взаимоотношения сотрудника и компании в следующих аспектах:

Жизненный цикл организации подразделения и сотрудника.
Взаимные ожидания сотрудников фирмы в зависимости от занимаемых ими позиций.
Работа в условиях турбулентности жизненных циклов фирмы, подразделений и сотрудников.

Надеюсь, что после моего рассказа некоторые люди лучше смогут ответить себе на вопросы:

Чего я хочу добиться на своем рабочем месте?
Как мне найти союзников по достижению профессиональных целей?
Чего от меня еще хотят, я же делаю свою работу?

Примерно так, приходите на SECR2011, буду вам очень рад.

http://www.secr.ru/lang/ru-ru/talks/company-employee-relationship-in-sme

Knowledge Management – я знаю, что вы знаете, что я знаю

Konstantin Bychenkov — Mon, 05 Sep 2011 05:00:07 +0000

Однажды, давным-давно, я пришел работать программистом в одну маленькую самарскую фирму, которая оказывала услуги офшорного программирования для рынка США. Россию в то время захлестнула волна Delphi проектов по автоматизации всего-всего. Телекомы, торговля, нефтедобыча, ERP. А тут я в другой мир попал, проекты могли быть о чем угодно. Как говорил директор – “Если нам завтра заплатят за проект на ЕС-ках – мы притащим ее с помойки советского НИИ и поставим в центре офиса”. Мне поручили программирование мобильных устройств, которых я до той поры и в руках не держал.

В общем, я попал в хорошие руки. И дело было не только в технике. С техникой все было сравнительно просто – было много литературы и много готовых проектов. Когда мне что то надо было узнать – я находил проект, в котором решалась аналогичная задача и человека, способного прояснить ситуацию. Работая над проектами я знал, что за люди мои заказчики, откуда они родом, чего ждут от нас, чего мы ждем от них, каков стиль работы и общей уровень их бизнеса, как с ними следует общаться. В общем – много всего, чего мне могли бы и не говорить. Мой менеджер оказался тем, что мне было нужно. Это и определило мою дальнейшую успешную работу. Я не просто старался сделать все, что в моих силах. Я знал производственный контекст, в котором я работал.

Эта удача называется “центр знаний”, который в этой фирме однозначно был и, надеюсь, никуда не делся. Он представлял собой группу менеджеров среднего звена, вокруг которых вращалась производственная активность. Помимо прямого управления командами они могли делать следующие штуки:

Прийти к тебе и рассказать как надо писать письма представителям клиентов вообще и тому конкретному, с которым ты сейчас в частности работаешь.
Где они уже встречали задачу, похожую на то, что ты собирался делать.
Какие книги следует прочесть конкретно тебе в первую очередь.
Какого тестера тебе лучше выбрать для тестирования данной конкретной задачи.
Что скажет руководство фирмы на результат работы.

Это знания, уникальные для каждого отдельного коллектива. Их не прочитаешь ни в одной книжке. Только своим опытом или опытом своих товарищей.

Все понимают что знания важны, но мало где их берегут. Часто, обычно под воздействием отраслевых стандартов и рекомендаций (ISO, PMBOK и т.п.) в фирме создают различные инструменты управления – создается информационный портал, назначается рабочая группа, организуются еженедельные планерки. И обычно скоро эти формальные усилия сходят на нет через какое то время.

Причина – в управлении знаниями не работает “инициатива сверху”.Топ-руководство просто не видит – где именно хранятся драгоценные знания. У руководителей высшего звена обычно другие приоритеты. Их больше волнует управление финансовыми потоками и отношения с ключевыми партнерами. И в общем-то, это правильно, потому что это как раз та работа, которую и должны в первую очередь делать “топы”.

Только менеджеры среднего звена могут наладить управление знаниями внутри своей организации, так как они больше всех в знаниях нуждаются и владеют ими. Именно поэтому в фирме, в которой я работаю умер корпоративный портал, но расцвели собственные порталы по отделам разработки. Может быть, это не идеальная ситуация, но эти порталы работают. Менеджеры среднего звена лучше других понимают какие знания нужны и где они лежат. К сожалению, как следствие тотального непонимания со стороны высшего руководства, знания – это то, что компании теряют в кризис вместе сокращениями персонала.

Что можно сделать для сохранения знаний, в условиях постоянной нехватки времени? Есть простые и неоригинальные средства, которые хорошо работают:

Самый очевидный совет- заведите таки для своих проектов портал, на котором будут не только текущие задачки, но и документы, ссылки, блоги, вики, форумы. Я лично не сторонник одного большого ресурса на всю фирму. Велик риск превратить хорошую идею в фикцию. Заведите портал для тех, кому он и правда нужен. Особенно хорошо этот инструмент приживается, когда им начинают пользоваться заказчики. Кстати коммуникаторы наподобие ICQ или Skype – это способ скорее потерять знания, чем найти.
Хорошо иметь на рабочем месте доску информации, на которой можно прикрепить сообщения, документы, контакты. Конечно, можно хранить все в электронном виде, но простая доска намного доступнее. Оперативные данные я часто помещаю на доске. Там у меня контакты заказчиков, краткосрочные планы и отчеты, записки на память. С доски практически ничего не теряется, в отличии от рабочего стола. Доска находится в общем доступе команды.
Ходите на корпоративные спортивно-увеселительно-всякие мероприятия. Это бесконечный источник полезной информации.
Используйте один канал связи. Старайтесь, чтобы вся информация проходила через корпоративную почту. Вместе с категоризацией содержимого почтового ящика и хорошим именованием тем ваша почта с каждым месяцем будет вам все дороже и дороже.

Это все самые элементарные и очевидные шаги, которые позволяют хоть как то накапливать и управлять накопленными знаниями. Для тех, кому интересно продолжение, могу порекомендовать некоторые ссылки:

Что мешает распространению знаний: http://kmonadollaraday.wordpress.com/2011/05/16/organizational-barriers-to-knowledge-management/
Роли, которые могут исполнять участники команды по управлению знаниями: http://www.nickmilton.com/2011/03/four-roles-for-km-team.html
И еще хорошая статья о том, что надо слушать своих сотрудников, что этому способствует а что – мешает: http://kmonadollaraday.wordpress.com/2011/08/08/listening-to-the-people-we-work-for/

Ну все, дальше как-нибудь сами Тема управления знаниями не перестает меня волновать, и продолжение этой статьи наверняка последует.

Еще несколько штрихов к плану коммуникаций

Konstantin Bychenkov — Sat, 28 May 2011 06:57:00 +0000

Будешь злым – повесят, будешь мягким – раздавят

(Татарская пословица)

С возвращением в мир проектов заказного ПО! Итак, конкурс выигран, контракт заключен, и мы продолжаем. То, что коммуникации — наиболее вероятная причина бед менеджера проекта, стало уже общим местом книг и статей по управлению проектами. Оно и так понятно. В конце концов ради коммуникаций менеджера проекта и нанимают. Из-за коммуникаций горят карьеры. Что же нам нужно, для того чтобы успешно наладить обмен информацией внутри команды и со всеми заинтересованными сторонами? Конечно, нам нужен план коммуникаций. И не говорите, что вам некогда сделать такой план. Вы же менеджер, у вас всегда есть план. Вы заранее должны подумать что, кому в какой форме и когда вы будете сообщать, а что — спрашивать. Остается только изложить этот план в документ, выделить в нем публичную часть и разослать всем заинтересованным сторонам.

Что потом бывает с такими планами? Они не работают! Большинство планов (на работе и в жизни) вообще не срабатывают, но тем не менее, это не повод отказываться от планирования совсем. Особенно в тонком вопросе коммуникаций. Вы же имеете дело с людьми.

Нас сейчас не волнуют все планы, а только план коммуникации. С ним то что обычно не так? План, это всего лишь план. Это наши ожидания, не более. В случае с людьми они особенно уязвимы. Уязвимость плана коммуникаций лежит в выборе каналов, в том, каким способом мы взаимодействуем между сомой. Вы планируете рассылать еженедельный дайджест о ходе работ по выполнению проекта, чтобы все всегда были в курсе того, что происходит, и вы легко могли обсуждать текущие проблемы. Через некоторое время, естественно, этот дайджест уже никто не читает. А вы то так старались! Обидно? Да, обидно.

Но давайте еще раз задумаемся, для чего вам вся эта «менеджерская чехарда» с планом? Для того чтоб все были в курсе? Не только! В первую очередь для того, чтоб никто не мог сказать «а я не знал, меня не проинформировали» или вообще «откуда же я мог знать, что будет письмо». Оттуда, из плана коммуникаций! На самом деле «Большой босс» вам все равно это скажет, но пусть уж это будет только он.

Разберем несколько типичных случаев коммуникаций и какой подход к их организации я бы советовал использовать

Большой босс. Главное, что вам нужно во взаимодействии с боссом — это доверие. Причем выбор времени и средств на налаживание контакта у вас сильно ограничен. Хорошо, если у вас в компании есть некая внутренняя культура общения, и она не сведена к формализму. Тогда у вас будет гарантированный шанс быть услышанным и есть каналы для этого. Или придется эту культуру вырабатывать. Немного правил, которым я следую:

Субъективно, самое эффективное для общения с шефом — телефонный разговор. Потому что переписки все равно не получается ввиду занятости шефа, а в разговоре успеваешь сделать две и более итерации по проблеме. Нет, встречаются и такие, кто по ночам на ваши письма отвечают, но это особый случай.
Разговор надо планировать, в том числе просчитывать ответы руководителя и готовить нужные документы, чтобы вовремя положить на стол. Для тех, кто сомневается, предлагаю пересмотреть фильм «Семнадцать мгновений весны», все эпизоды с группенфюрером Мюллером. Энциклопедия менеджера.
Письма нужны в первую очередь для постановки проблем и информирования о ходе дел. Они должны быть короткие.

Конкурент. Уровень доверия на нуле. Зачем вам вообще общаться с конкурентом? Затем что вы работаете не в вакууме и вы «не один в израильской армии» , то есть не один у заказчика. И, при встрече придется демонстрировать партнерство и готовность к сотрудничеству. А потом, неизвестно как дело сложится, сегодня вы конкуренты, а завтра — добрые партнеры.

Найдите канал, который даст наиболее надежный контакт. Нам важно, чтобы по ту сторону баррикады нас услышали и однозначно поняли.
Обязательно получите обратную связь любым способом.
Постарайтесь хоть с кем то из представителей конкурирующей организации поддерживать благожелательные отношения в личном плане. На любой войне нужны парламентеры, а потом — нужно иметь возможность обсудить дела нормально и в будущем. как знать, может быть ваши фирмы станут партнерами. На до будет с кого то начинать добрые отношения.ё

Заказчик. Что вам нужно от заказчика? Чтобы вы видели проект одинаково.

Чем подробнее — тем лучше. Без фанатизма конечно, но информировать максимально. Информировать о прогрессе работ, о расходовании бюджета.
Заранее узнайте, что интересует заказчика. Я не о целях проекта из предварительного видения, а о том, что интересуют каждого представителя заказчика в в вашем проекте лично. Найдите всех лиц, которых надо информировать, выясните субординацию между ними.
Подумайте о том, какую информацию вы будете посылать сразу по почте, а какую все таки сначала обсудите с заказчиком. Не подымайте панику в лагере клиента, это не в ваших интересах.
Признавайте ошибки.

Пользователь. Пользователь нужен для того, чтобы ваш проект ожил. Недовольные пользователи сведут на нет все усилия, долгосрочных отношений с клиентом не получится.

Поймите как ваш продукт повлияет на жизнь пользователей. Им станет легче работать или наоборот — будет больше обязанностей? Отталкивайтесь от этого при построении общения.
Найдите «пользователей-чемпионов» которые будут локомотивом для остальных. Но, не переусердствуйте, надо чтоб пользователи понимали, что важно мнение каждого.
Последовательно отвечайте на вопросы пользователей. Если не можете сами сразу , отложите вопрос. найдите ответ и донесите до пользователей. Пользователи ничего не забывают и считают очки за и против.
Создайте несколько каналов связи. Форум, блог, телефон, личные встречи.

Вот так и живем. Общение — самое интересное в работе над проектом, хотя, иногда от общения устаешь. Развивайте навыки устного и письменного общения, это точно поддается тренировке. Выступайте на публике, пишите и читайте статьи, ходите на отраслевые конференции и встречи с коллегами. Менеджер, избегающий такой активности, упускает очень многое и выглядит довольно подозрительно.

В конце — немного чтива на тему этой статьи, все на английском. Обратите внимание что и сами блоги очень и очень интересные, не только отдельные приведенные мною статьи.

Real World Project Management: Communications — простая статья, которая поможет вам выработать правильное отношение к профессиональному общению.

Effective Project Communication Management — статья с большим содержанием умных слов. Надо ее прочесть, отметить все умные слова и найти их потом в поисковике. Тогда вы станете гуру по коммуникациям

PS: если кто то надумает написать комментарий к статье, пусть укажет в нем какое то одно свое правило коммуникаций.

Первая встреча самарского сообщества менеджеров проектов

Konstantin Bychenkov — Wed, 11 May 2011 22:15:57 +0000

Если кто то решил, что я свой блог совсем забросил – таки нет! Просто было много дел, а еще мы с Александром Калугиным организовали встречу менеджеров проектов по разработке ПО. Вот протокол в моем исполнении:

http://pmsamara.blogspot.com/2011/05/blog-post_11.html

Следите за новостями!

Для тех, кто впервые на родео

Konstantin Bychenkov — Sun, 13 Mar 2011 15:23:22 +0000

«Why so serious?» (Joker)

Кто же не любит давать советы новичкам?! Или сидя в лодке, подальше от берега, кричать неуверенно стоящим на берегу пловцам «Ну чего вы там?! Плывите сюда!» Выпимши 100 грамм настойки, «для куражу», хочу продолжить дело, начатое Сашей Калугиным в его статье «Менеджер-начинашка». Какие мысли хорошо бы чтоб пришли в вашу голову в начале пути?

Мысль 1. «Оно вам надо?» Специфика дела менеджера проекта такова, что мало кто приходит в эту профессию со школьной скамьи. Обычно, у новичка есть опыт работы программистом, а в случае интернет-проектов, часто функции менеджера берет на себя маркетолог. И вот в один прекрасный день вам предоставляется новая возможность, ура! Или вы оказались самым активным в команде, или просто у вас самый большой рабочий стаж — но предложение последовало. «Ура»? Если вы действительно перспективный менеджер, то такие предложения будут к вам поступать и в будущем, а вот возврата в изначальную профессию может уже не быть. Поэтому, принимая предложение, подумайте — куда вы придете лет через пять и нравится ли вам это место? У профессиональной деятельности должна быть цель. До сих пор на собеседованиях я привожу людей в замешательство простым вопросом — «Как вы видите свое профессиональное будущее через три года?» Вы, как менеджер, должны всегда знать ответ на такой вопрос, потому что планирование деятельности ваша физиологическая особенность.

Мысль 2. «Кто я?» После того, как первая мысль покинула вашу пока еще светлую голову, оставив в ней глубокую борозду и одновременно чувство легкости и уверенности в правильном выборе, переходим к самоидентификации. Без этого вам не заслужить такой нужный авторитет руководителя. Хорошо, если вы выросли внутри команды, и все знают как вы круты и все основные модули в коде проекта — за вами. Или вы и придумали концепцию и бизнес-модель проекта. А ну как нет? Становясь менеджером проекта, необходимо осознать свою роль. Это определяет какого рода активность выбудете выполнять самостоятельно, какой — избегать, а какую — делегировать. Лично я для свою миссию характеризую так: «1) Вести команду к поставленным целям; 2) Устранять препятствия на пути к цели». Но это не единственный правильный вариант ответа. Кому то удается совмещать управление и разработку, кому то нет. Должен вас предупредить еще об одной ловушке, которая поджидает многих. Хороших предложений в управлении проектами меньше, чем например, в разработке. Особенно, если вы живете не в Москве. Так что надо быть очень клевым или все таки не терять свою основную профессию. Ох, не раз я слышал от своих коллег «Как только потеряешь технические навыки, так об тебя и начнут ноги вытирать», ох не раз. Что же такое клевый менеджер? По мне, это специалист, который не только распасовывает задачки, но еще и способен помочь бизнесу компании. Менеджер, который закрывает бизнес-направление, ценится куда дороже, чем простой модератор корпоративного тасктрекинга. У вас должна быть деловая мотивация. Ваша победа в успехе бизнеса вашей компании.

Сразу две мысли на одну статью — это слишком расточительно, опытные блоггеры так не делают. Но я люблю своих немногочисленных, но преданных читателей, и мне не жалко. К тому же, перечитав материал, я нахожу его мрачноватым. Я не хотел! Ребята, я желаю удачи всем смельчакам, которые бросаются в это непростое ремесло. Вам не будет скучно, обещаю! А что мысли мрачные — не беда. Если вы все таки станете менеджером, думать вам уже много не придется. Просто станет некогда (шутка)

Эффективность команды. 1 пишем–2 в уме

Konstantin Bychenkov — Sun, 06 Mar 2011 05:45:18 +0000

Как то мне в голову пришло посчитать как изменялось соотношение стоимости команды к количеству сделанной работы на протяжении двух с половиной лет. Итоги меня в целом порадовали — стоимость разработки одной истории за указанный период упала в среднем в два с половиной раза. Во многом мне помог и довольно низкий старт, но все таки. «Вот она, эффективность» сказал себе я и, довольный, набрал в поисковой системе «team effectiveness in IT’» чтобы посмотреть, а что же вообще в мире то делается на тему эффективности.

Информации конечно, очень много. Эффективность команд одна из излюбленных тем для исследований. В России это еще и одна из самых популярных тем для тренингов — тимбилдингов. Отмечу только то, что «зацепило» лично меня.

На сайте The Korn/Ferry Institute я нашел интересный обзор моделей эффективности команд. Представлено семь разных ответов от разных исследователей на простой вопрос — «Что такое эффективная команда?» За что я люблю зарубежные академические работы по деловой тематике, так это за то, что они могут о сложном говорить простым английским языком. Это как раз тот случай. Наши по русски так могут далеко не всегда. Для тех, кто хочет посмотреть на проблему эффективности под разными углами и потом где-нибудь блеснуть эрудицией, — очень советую.

Понравился блог Technology of Doing который сфокусирован именно на эффективности IT команд. Авторы делятся там собственным практическим опытом, меньше теории — больше практики. Forming, storming, norming и так далее. Отдельно отмечу статью Behavior Driven Hiring о том, как распознавать и нанимать нужных вам людей.

Знакомясь с найденными материалами, я отметил для себя один момент. Эффективность вообще — это когда работа делается хорошо, а затраты при этом невелики. У эффективности все таки две стороны — повышение производительности и снижение издержек. Так вот, про издержки пишут очень мало, тему денег избегают. Отчасти могу объяснить это тем, что вопрос обычно тривиален. Если у вас средненькая локальная фирма, то вы все равно будете платить рыночную стоимость, принятую в данной отрасли в данной местности. Никуда не денетесь, отклонение в ту или другую сторону будет небольшое. Останется повышать эффективность команд только путем построения производственного процесса. Иное дело транснациональные корпорации. На глобальном рынке труда появляются новые возможности снижения издержек.

Вопрос денег существенно влияет на эффективность, потому что это напрямую касается мотивации команды. Эта мотивация — авторская (гонорар, признание, интересная работа). И никакие процессы, тимбилдинги и корпоративы не компенсируют проблемы с мотивацией. Спрос на специалистов в IT достаточно велик и будет расти на фоне надуваемого пузыря венчурных инвестиций в стартапы. Я считаю, что традиционные методы оплаты труда уже неэффективны. «Просто оклад» — расхолаживает сотрудников. Из своего списка способов оплаты инженерного труда я пока склоняюсь к п.3 — фиксированная заработная плата и бонус (премия). Да, ребята, мы живем при капитализме. А уже с мотивированной командой можно идти в бой, строить отношения, производство, проводить тренинги. Иначе — не в коня корм. Про мотивацию, рынок и деньги советую заглянуть еще в ЖЖ к Якову Сироткину. Своевременная статья!

Ну и пример командной работы. Команда —это сила! Заметьте, у команды на льдине есть а-а-а-аатличная мотивация

Сила команды

Мотивация. Нам не все равно!

Konstantin Bychenkov — Sat, 15 Jan 2011 22:34:37 +0000

Самара — город маленький. Все друг с другом знакомы и одни и те же люди переходят с одного рабочего места на другое, пока не найдут себе гавань по душе.

-А Федя у вас сейчас над чем работает? — спросил я друга, после того как мы поставили на стол кружки с пивом. Федей гордились в фирме.

-Ни над чем. Последнее время от него получали отговорки вместо результата.

-Интересно, почему? Он был клевый… Вы и платили ему хорошо.

-Был, но так со всеми бывает, как поломался.

Я согласно кивнул и сделал большой глоток. Такие истории меня уже давно перестали удивлять.

Мотивация — то, что нужно нам всем. «Труд станет потребностью!» предсказывали классики марксизма. Время показало, что это скорее заклинание вуду, чем научный факт.

Мотивация — веская причина делать свою работу как можно лучше. Про то, как найти такую причину для своих сотрудников, написано очень-очень много всего-всего. Из того, что попало в круг моего внимания, могу предложить список правил, с которыми я согласен:

Уважайте своих сотрудников. Не врите, не пытайтесь манипулировать людьми.
Создайте хорошие условия труда.
Интересуйтесь мнением сотрудников и покажите им, что их мнение влияет на ситуацию.
Обсуждайте проблемы. Нет аутичному менеджменту.
Сформулируйте систему поощрений и наказаний, понятную для сотрудников
Не создавайте бессмысленных ограничений и требований. Особенно таких, которые не сможете применить. Ведите себя достойно.
Высокая зарплата не является средством мотивации. Однако, низкая зарплата — мощное средство демотивации. Кстати про зарплаты у меня кое что есть в моем блоге.

Еще есть целая книга «Не мешайте мне работать» Стаса Давыдова, довольно толковая, вся в том же духе. Это «правила хороших парней». Соблюдая их, вы несете свет в этот несовершенный мир. Суть их сводится к тому, что надо последовательно развивать дух сотрудничества в фирме и заслужить уважение сотрудников. Будь лучше и люди к тебе потянутся! Но правила не гарантируют результат, увы.

А еще у меня есть собственные наблюдения по мотивации. На новизну не претендую:

Мотивационная программа предприятия начинает работать уже в момент рекрутинга. Если ваша контора может себе позволить набирать сотрудников по заранее заданным параметрам, то это очень крутая контора. Можно набирать молодых неженатых парней сразу после института, живущих с родителями в отдел R&D и 35-летних отцов семейств с ипотекой и автокредитом в саппорт. Тогда можно будет использовать единые подходы к мотивации (и не только), так будет дешевле. Но для осуществления этого плана надо чтоб в дверь офиса выстроилась очередь соискателей вакансий.
Проводите показательные казни. Увольнение слабых звеньев команды прекрасно мотивирует оставшихся. Но эффект гаснет со временем и возможно привыкание. Конечно, приговор должен быть обоснован. Кстати, уволить по ТК не так-то просто!
Бессмысленно мотивировать коллектив, в котором демотивированы менеджеры. Рыба гниет с головы. Так же для успешного мотивирования менеджеры должны быть профессионалами, а не просто разработчиками, которых назначили старшими. Это разные культуры, у меня пара лет прошло, прежде чем я себя до конца менеджером осознал. У разработчиков мотивация обычо авторская (интересная работа, деньги, известность) у менеджера должна быть деловая мотивация (прибыль, успех).
Рано или поздно, но мотивация заканчивается у каждого. Поэтому глупо держаться за человека до последнего и глупо спрашивать себя «Почему? Ведь нам было так хорошо вместе!» Было и прошло.
На мотивацию влияют не только факторы внутри фирмы, но и за ее пределами. Зарплаты в соседних конторах, цены на недвижимость, успехи коллег из других фирм. Все это влияет, и разрабатывая мотивационные планы , нельзя отрываться от реальности.

Желание мотивировать сотрудников возникает однажды у каждого руководителя. Чем выше поднимаешься по служебной иерархии, тем сильнее ощущение, что с твоими подчиненными что то не так. И разобраться уже нет времени. В случае, когда у меня возникает такое подозрение, я стараюсь разбираться, начиная с себя. Это вообще, очень интересно и полезно. Кто еще не пробовал – самое время начать!

Дай качество! Шанс, он не получка не аванс.

Konstantin Bychenkov — Sun, 26 Dec 2010 07:19:23 +0000

Эта статья является продолжением нашего с Александром Калугиным спора о том, чем должны заниматься специалисты QA\QC в небольших проектах.

Я кажется уловил суть нашего спора. Мы с Александром по разному смотрим на шансы, которые команда может использовать в достижении успеха проектной деятельности.

В принципе, читатели уже вполне могут оценить наши позиции и сделать свой выбор. Во многом этот выбор будет обусловлен средой, в которой инициируются и развиваются проекты. И понятно, что абсолютной истины мы не достигнем! Еще раз начнем с вопроса — что такое «качество».

В понятии качества, согласно стандарту SQuaRE (Software Quality Requirements and Evaluation), много чего есть:

Функциональность — да, то самое соответствие требованиям! То, что делает приложение пригодным к использованию;
Надежность — насколько хорошо система работает за пределами штатных ситуаций;
Удобство — мы все знаем что это, как это выразить словами? Простота работы с продуктом. Очень субъективно;
Эффективность — различные количественные показатели по времени работы и использованию ресурсов;
Сопровождаемость — насколько система получается изменяемой, проверяемой. Модернизация и поддержка должны обходиться недорого;
Переносимость — насколько система независима от своего программно-аппаратного окружения.

Вот где-то среди этих шести пунктов затерялось качество спецификации и соответствие архитектуры решаемым задачам. Причем, если проект маленький, то как правило, спецификация или тривиальна или ее качество невысоко и с этим все мирятся. Кто удивляется, почему это так, пусть откроет Вигерса и прикинет, сколько стоит качественно отработать все активности для обеспечения достойного уровня документации. И где будет вас ждать заказчик с вашей «достаточно хорошей спецификацией»? Есть видение — и на том спасибо. Так что тут я с Сашей согласен. А вот выводы у меня свои.

Качество архитектуры — это то, о чем я у QA поинтересуюсь в самую последнюю очередь. И не надо на меня обижаться. Именно за счет того, что QA/QC далеко от пользователя, заказчика и условий контракта, мне не очень то интересно их спрашивать про архитектуру. Я лучше спрошу тех, кто в проекте выполняет роль аналитика и архитектора.

В такой ситуации лучшее, что может дать QA/QC, — это честно и до конца сделать свою работу. В условиях итеративного подхода, где все может поменяться в любой момент, это особенно актуально и наиболее востребовано. Пусть эти ребята скажут, где правда, где ложь, а где они не знают что проверять и с чем сравнивать. Попутно пусть расскажут, где им удобно а где не очень. Могу напомнить, что еще есть много работы по составлению и поддержке тест-кейсов, формулировке атрибутов качества, анализу дефектов, автоматизации. Если эти процессы налажены, то я предлагаю заняться их качеством в первую очередь. Улучшение собственной деятельности не знает границ.

Я в общем то не против. Если у QA есть сомнения в спецификации и ли в архитектуре, — пусть высказываются. В команде никто не должен ничего «держать в себе». Но, пусть понимают, что главная их обязанность в другом. Необходимо расставить приоритеты. И у меня большие сомнения в существенности вклада QA/QC в анализ бизнес-целей или поиск рисков. Не тем будут люди заниматься, ох не тем. А в маленьком проекте шанса все наверстать в своих прямых обязанностях может и не представиться.

И тогда тот, кто за все платит в вашей фирме может задуматься – а не сэкономить ли ему на ФЗП за счет QA/QC?

PS: Пытливому читателю я предлагаю открыть книгу “Wiegers K.E. – Software Requirements” и найти, где в ней упоминаются специалисты QA и в каком контексте.