Коммуникации

IT-Spring’2012: ждем продолжения…

В минувшие выходные состоялась конференция IT-Spring. Очень интересные очерки о конференции были опубликован сообществом белорусских аналитиков.

Лично мне хочется сказать огромное спасибо организаторам – конференция получилась классная! Надеюсь, что через некоторое время состоится IT-Spring’2 :).

С организационной точки зрения – все было на очень высоком уровне, спасибо Oxagile, и лично Дмитрию Здановичу и Валентине Пушкиной. Но кое-что можно улучшить :

Бэйджик – должен быть двусторонний (с булавкой или шнурком), иначе непонятно куда крепить эту прищепку, если карманов нету?
Мало кофе – ребят, это ж IT-шная конференция! горючее-то надо было всё-таки подвезти…
Формы обратной связи – отдельная страница текста на каждый доклад – это слишкам много букафф…
Секции B и C – не было модераторов, которые бы следили за регламентом и расписанием, а самое главное – не было пультов-презентеров для докладчиков, что очень неудобно. Также зал C был рассчитан где-то на 50% заполнение. При большем количестве слушателей – все впадали в неадекват из-за духоты.

С содержательной стороны вопроса все было тоже замечательно.

Continue reading →

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

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

Atlantic Systems Guild “Балдеющие от адреналина и зомбированные шаблонами”

Мой заядлый друг Константин Быченков так прокомментировал первую часть моей статьи:

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

Вообще говоря стажировка – это по определению издевательство над стажером. К сожалению, иначе не получается! Формализацией и зрелыми процессами в организации можно покрыть все же только hard skills. Основные же проблемы возникают все же с soft skills, которые не формализуемы. Continue reading →

Команда / Коммуникации / Процесс / Риски — 4 Comments
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 →

Agile / Качество / Команда / Коммуникации / Процесс / Управление проектами — 1 Comment
28
Окт 11

О зрелости в Agile и заказной разработке ПО

В большинстве профессиональных организаций перспектива повышения остается главной движущей силой среди исполнителей низшего звена.
Д. Майстер, «Управление фирмой, оказывающей профессиональные услуги» (гл. 16)

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

Одним из приглашенных докладчиков начинающейся на следующей неделе конференции CEE-SECR будет никто иной, как Джеф Сазерленд (Jeff Sutherland). В своём интервью PCWeek, опубликованном на сайте конференции, Джеф отметил, что все больше компаний требуют процесса SCRUM от своих аутсорсеров, и повторил своё же утверждение из ставшей классикой Scrum and XP from Trenches о том, что его венчурная компания инвестирует только в компании, практикующие SCRUM.

What would you like to say to PC Week magazine readers and Russian software developers?
Well, I’d to say that we know that certain practices change the world, change the market, change companies. If Russians are interested in being a major force in software development then SCRUM is a fundamental tool that they need to learn how to do, and how to do well. What we find is that more and more people are demanding SCRUM companies for any outsourcing. Or, from the point of view of my venture company, we invest in companies all over the world, and we only invest in SCRUM companies. So I would say to Russian developers, if you want to do better in the market, if you want to bring more software development in house, if you want to start companies that build software, then SCRUM is the best tool available today to do that.

Также Сазерленд указал, что SCRUM – лучший доступный на настоящий момент инструмент, который может помочь компаниям в более эффективной организации внутренних служб разработки, компаниям, строящим ПО… Но он ни слова не сказал о заказной разработке ПО!

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

Асхат Уразбаев говорит (см. http://www.slideshare.net/Askhat/scrum-5545482) о длительных проектах по заказной разработке ПО, фокусируясь на достижении в рамках таких проектов реальной бизнес-ценности для заказчика в условиях меняющихся требований. Борис Вольфсон в своей статье (см. http://habrahabr.ru/company/softline/blog/124030/) пишет о Time-n-material как идеальной win-win форме контрактов, построенных на доверии с заказчиком, «подсаженным» на «итеративную иглу». Алексей Кривицкий в своем недавнем докладе (см. http://www.krivitsky.com/2011/10/offshore-outsourcing-and-agile.html) говорит о правильном подходе к оффшорной разработке ПО в стиле Agile – как к построению долгосрочных матримониальных отношений с командой, об отношении заказчика к команде разработки как к собственным друзьям или детям…

Возникает ощущение, что в российской Agile-среде произошло некоторое отождествление понятий аутсорсинга разработки ПО и заказной разработки ПО (пусть даже и по T&M контракту).

С моей точки зрения, в этой терминологической путанице коренятся многие иллюзии эффективности Agile-методологий в соответствующих проектах. В этой заметке мне хочется внести некоторую ясность в сложившуюся ситуацию и разобраться всё-таки в применении Agile, и в частности SCRUM, в проектах заказной разработки ПО fixed-scope – наиболее распространенной форме для небольших проектов.

Continue reading →

Команда / Коммуникации / Процесс / Управление проектами — 4 Comments
4
Окт 11

Команда программистов-экстравертов, или «А может быть, всё наоборот?»

По-моему, конец света всё-таки где-то рядом… По результатам исследований кубинских ученых, большинство программистов имеют MBTI-тип ESTJ. По классической теории, этот тип (логико-сенсорный рациональный экстраверт) считается идеальным для менеджеров-администраторов, но никак не для программистов! А еще Brogramming… Куда катится этот мир…

Программирование всегда считалось уделом интровертов. С. Архипенков в своих работах со ссылкой на классиков называет два MBTI-типа, наиболее часто встречающихся среди программистов, оба из которых – интровертные:

Специфика программистской работы обуславливает общность психологических черт большинства профессиональных разработчиков ПО. Достоверных данных статистических исследований найти не удалось, однако, по мнению С.Макконнелла, которое очень хорошо подтверждается моим личным опытом общения с коллегами, большинство разработчиков ПО принадлежит к двум типам:
«Инспектор» — ISTJ = I (интроверт) + S (конкретное восприятие) + T (логик) + J (рациональный).
«Аналитик» — INTJ = I (интроверт) + N (опирающийся на интуицию) + T (логик) + J (рациональный).

Получается, что за последние несколько лет всё принципиально изменилось? Из-за глобального экономического кризиса программисты-интроверты вымерли, как динозавры? Или интровертность программистов просто была всеобщим заблуждением?

Если все программисты – экстраверты, то, подходя к проблеме изменения процесса разработки «в лоб», наверное, стоило делать всё наоборот.

Вместо состояния потока –> непрерывное общение.
Вместо чатов и переписки -> митинги, митинги, митинги.
Вместо глубокого анализа проблемы –> brainstorming.
Вместо отдельных кабинетов –> open-space.
Вместо погружения в один проект -> постоянные переключения между несколькими…

Что-то даже мне жутковато… У меня большие сомнения, что такие экстремальные меры были бы по душе даже самым отъявленным программистам-экстравертам!

С другой стороны, вероятно, строить процесс так же, как и с «socially-challenging»-интровертами, – тоже неверно. Имеет смысл хотя бы задуматься об особенностях программистов-экстравертов, которые стоит учитывать при формировании команды, распределении задач и построении процесса разработки. Этой теме и посвящена моя заметка.

Continue reading →

Качество / Команда / Коммуникации / Процесс — 2 Comments
18
Сен 11

Черный ящик Пандоры

Никогда не задумывался о том, что процесс тестирования — это не просто работа с черным ящиком, но работа с двумя черными ящиками!

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

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

Continue reading →

Архитектура / Коммуникации / Процесс / Риски / Требования / Управление проектами — 7 Comments
13
Сен 11

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

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

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

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

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

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

Continue reading →

Коммуникации / Процесс / Требования — 8 Comments
18
Июл 11

Взрывоопасные требования или был ли аналитик?

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

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

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

Команда / Коммуникации / Конференции — 3 Comments
31
Май 11

Конференция Stratoplan.ru

Я решил присоединиться к онлайн конференции Stratoplan.ru которая пройдет 4 июня c 10.00 до 14.00

Конференция бесплатная и стихийная , а значит объединяет людей, которым действительно есть, что сказать. Учитывая количество заявок на участие по состоянию на 30 мая, конференция обещает быть едва ли не самым масштабным событием лета 2011 года в IT-индустрии.

Прочитать подробный анонс и зарегистрироваться на конференцию можно на сайте it4business.ru или happy-pm.com

Ниже — тезисы моего доклада. Приходите, будет интересно

Motivational Debt & Software Engineering или «не все задачи одинаково полезны»

Очень многое сказано про то, КАК необходимо правильно ставить задачу, о soft-skills менеджера при взаимодействии с командой, об эффективных методах мотивации, и т.д.; но в процессе мы как-то забыли о том, что не все задачи обязательно одинаково полезны. Даже если два таска на новые фичи одинаковой трудоемкости сформулированы в совершенном духе SMART (так что не подкопаешься!), сама суть задач может быть настолько различной, что одна из них будет демотивирующей, а вторая — сильнейшим мотиватором.

В докладе я расскажу:

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

Эти знания помогут менеджерам и dev-лидам более эффективно распределять задачи в команде и не создавать задолженности по motivational debt.

Команда / Коммуникации / Управление проектами — 1 Comment
28
Май 11

Взаимодействие с технарями. Part #2

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

Двумя наиболее яркими и наиболее специфичными примерами таких представителей являются участники QC и DEV команд заказчика.

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

Большие проблемы маленьких проектов и их решение