Риски


14
Фев 12

Стажировка менеджера проекта, или советы ментору, как догнать двух зайцев и не заработать невроз. Часть 1

Обучение менеджера проекта по разработке ПО чаще всего проводится в форме «воспитания Бабы Яги в собственном коллективе» – то есть передачи знаний и навыков от менеджера-ментора опытному сотруднику компании, до этого исполнявшему иную роль – например, dev lead’а или QA-lead’а).

Хочешь – не хочешь, но такое наставничество должно обязательно завершиться стажировкой, иначе навыки новичка – особенно soft skills – просто не сформируются.

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

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

Continue reading →


27
Дек 11

Шесть советов по взаимодействию с team-lead’ом для опытного разработчика, ставшего опытным менеджером

Despite the inability of most software developers to become people managers, it seems that the selection of non-technical people is an even worse choice for management of technical people.

Jurgen  Appelo Blog

Интернеты пестрят статьями о том, что менеджеры-технари – это ошибка природы. Последние исследования Google показали, что технические навыки – наименее востребованные из навыков менеджера. В последнее время заметен однозначный тренд в сторону «нетехнических» менеджеров проектов. Причин тому много – например возвращение менеджеров-технарей на техническую стезю. Индустрия научилась делать работу «нетехнических» менеджеров эффективной даже в технически очень сложных проектах. Исследования, проведенные PMI в далеком 2004 году, показывают, что уже тогда среди группы менеджеров-респондентов более 95% руководили техническими проектами, но меньше половины из них имели технические навыки в соответствующей области.

Но какой ценой все это далось? Саша Орлов в своем блоге высказал интересную мысль:

Оглядываясь назад и по сторонам, я заметил, что во всех знакомых мне успешных командах, где менеджер был не техническим человеком, всегда был сильный технический лидер. Это очевидное наблюдение. Неочевидное же заключается в том, что менеджер и тех.-лид работали в плотном тандеме. Тех.-лид, например, в публичных обсуждениях никогда не подвергал сомнению авторитет менеджера. Более того, своим поведением тех.лид как бы говорил: «Мы работаем вместе, я силен в технической части, ты силен в других вещах – отношениях с клиентами, администрировании бизнеса и т.д.»

То есть получается, что всё-таки нужны и технические, и управленческие, административные, коммуникативные – если хотите, менеджерские навыки, просто их сложно совместить в одном человеке. Это подтверждает и Скотт Беркун:

Of course there is nothing mutually exclusive between being a great programmer and being a great manager. These people exist. But they’re rare.

Но, всё-таки такие менеджеры встречаются! В отчете PMI всего 50% были не технарями…

Да, в начале менеджерского пути у бывших технарей куча проблем. Об этих проблемах писали уже все кому не лень, даже я (см. заметку «Менеджер-начинашка» и серию «Случаев из жизни…»: случай #1,случай #2 и случай #3). Но большинство этих проблем – неспецифические, это просто проблемы неопытного менеджера! Программистское прошлое на начальном этом этапе значения не имеет или даже работает «в плюс». А вот дальше ситуация меняется…

В приведенной цитате из блога Саши Орлова у менеджера-профессионала и технического lead’а формируется тандем, который позволяет им мирно и эффективно вести проект. А как быть тому несчастному, который из опытного, хорошего team lead’а, пройдя все тернии и горнила, стал-таки классным менеджером проекта? С одной стороны, он счастливчик – и нашим, и вашим… Но получается ли у него так же эффективно наладить процесс коммуникации с собственной командой, построить отношения с другим team lead’ом? Об этом моя заметка.

Continue reading →


7
Окт 11

О конференциях

Вот и завершился сентябрь и уже чуть-чуть октября а с ними и две осенние конференции WhaleRider и 404fest. Такие разные по масштабу, по тематике, по атмосфере, но обе безумно интересные!

На WhaleRider мне очень понравилось выступление Стаса Фомина про мясокомбинат из программистов, до сих пор хожу под впечатлением! Хочу написать развернутый пост в ответ Стасу! Слайды моего выступления на WhaleRider доступны на сайте конференции.

На 404fest, как и всегда, масса друзей и интересной информации. 404fest становится статусным событием: на фестиваль в этом году пришел мэр Самары. Очень понравился доклад Даниила Колесникова и Алексея Пономаря. Сам в этом году активно участвовал в работе секции Мобильных приложений. Слайды презентации с 404fest на сайте конференции недоступны, поэтому вот они:

Исходные файлы презентаций докладов доступны в разделе материалов:

http://pmarcor.com/my-safe/


25
Сен 11

Когда головоломки побеждают: мотивация команды в технически сложных проектах с затяжной отладкой

Обожаю Angry Birds!  Очень затягивает! Иной раз приходится поднапрячься, пока замочишь свинтуса… Иногда руки опускаются, и невольно вспоминаешь про Mighty Eagle

А еще, в детстве, была такая игрушка  - The Incredible Machine. Каждый раз улучшается настроение, когда вспоминаю…  Для тех, кто не помнит, объясню суть игрушки: нужно собрать достаточно странные и на первый взгляд несовместимые элементы типа вентиляторов, качелей, летающих кошек, бейсбольных мячей и т. п. в единый механизм и запустить его в действие. Если механизм собран правильно, то он произведет некоторое требуемое действие – и ты перейдешь на следующий уровень.

Как только соберешь все детали вместе – решение кажется простым и прозрачным.  Но пока собираешь, все далеко не очевидно, и от досады порой забрасываешь уровень на неделю или дольше… пока не придет озарение.

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

Continue reading →


13
Сен 11

Ой, забыли… опять про ошибки забыли…

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

‘Error while trying to retrieve text for error ORA-XXXXX’

По-моему, «апофигоз» бессмысленности и безобразности! И не от кого-то, а от самой Oracle!

Вообще, сообщения об ошибках и исключительных ситуациях – это какая-то системная проблема отрасли разработки ПО. Несмотря на то что соответствующие вопросы включены в SWEBOK в качестве ключевых вопросов проектирования, это по каким-то непонятным причинам никого не волнует!

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

Continue reading →


29
Авг 11

Ужасы нашего городка: риски разработки для разработчиков ПО

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

Т. Демарко, Т. Листер, «Вальсируя с медведями»

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

Большая часть существующей литературы, посвященной управлению рисками, рассматривает общефилософский вопрос «Почему так важно управлять рисками?». К  примеру, авторы классической книги «Вальсируя с медведями» Т. Демарко и Т. Листер основное внимание уделяют именно идеологии и психологии управления рисками.

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

EVM (Expected Monetary Value) = P (Probability) x I (Impact).

Что делать в ситуации, когда абсолютно непонятно, как вычислить требуемую вероятность, остается за кадром.

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

Для таких случаев еще не придумали ничего более эффективного, чем кондовый checklist-«склерозник», который позволяет быстро освежить в памяти типовые грабли, уже попавшиеся под ноги в прошлом, и, как следствие, помогает обойти аналогичный садовый инвентарь в будущем. Именно «хит-параду» технологических рисков в разработке ПО и посвящена эта заметка. Continue reading →


27
Апр 11

О рефакторинге, или когда долги лучше не отдавать…

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

А так как мы, как менеджеры – добропорядочные граждане, понимаем, что долги, даже технические, надо отдавать… Мы собственно стараемся их вернуть при первой возможности (ну, по крайней мере стараемся…)

Однако есть ситуации, когда идти на поводу у команды разработчиков и проводить рефакторинг — далеко не во благо проекта. Мало того, – это просто-напросто опасно! Вот две из них Continue reading →


18
Мар 11

Аномальные проекты или как из кота может получиться пёс…

Обычно считается, что специалисты QA высокого уровня должны обладать хорошей аналитической квалификацией, чтобы проектировать эффективные тесты.

Но есть один аномальный тип проектов, когда, в дополнение аналитическим скиллам тестировщиков, аналитику требуется очень высокая квалификация в свободном тестировании. Continue reading →


7
Фев 11

О метриках и переоткрытых багах


Вообще говоря, я скептически отношусь к статистическим метрикам; их развелось жуткое количество… KLOCs, code coverage, bugs per LOC, и т.д. Одна лучше другой! В маленьких проектах, метрики дают слишком большую погрешность, чтобы на их основании принимать какие-либо решения. Часто они больше мешают, чем приносят реальную пользу.

Но одну метрику я реально использую на практике: доля переоткрытых багов. Чтобы вычислить эту метрику надо поделить количество дефектов в определенной функциональной группе, которые были повторно обнаружены (переоткрыты, reopened) в следующем билде, на суммарное количество пофикшенных (switched to ‘testing’ state, resolved fixed) багов в текущем билде. Если эта величина достигает 100% — мы можем иметь дело
с тепловой смертью проекта:) .

Но, кроме шуток, с моей точки зрения, если несколько итераций в проекте дают большое количество багов в одной и той же функциональной группе (новых или переоткрытых) – это очень тревожный звонок. В процесс разработки необходимо вмешаться, выяснить причину происходящего и принять меры.  Иначе, есть риск, что несмотря на значительные затраченные усилия разработчиков и QA,  проект может начать «буксовать». Continue reading →


3
Янв 11

Спор о качестве. Часть 2

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

Но что же является прямыми обязанностями QA/QC? Даже если рассматривать эти обязанности в узком смысле, как тестирование – то целью и задачей QA является обнаружение всех дефектов, причем обнаружение наиболее критических дефектов как можно на более ранних стадиях тестирования.

Как же можно выполнить эту задачу более эффективно, чем через анализ на ранних стадиях архитектуры и спецификации требований? Continue reading →