№12 Вы позади конкурентов? Выпускайте продукт чаще и с новым содержанием

Если конкурент "обогнал вас на круг", то есть, если он на одну или несколько версий впереди вас, - то ситуация опасная. Требуются внезапные решительные коренные изменения.

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

Не делайте ни каких предварительных объявлений. Хотя вам захочется похвастаться невыпущенным ПО и дать клиентам луч надежды, - не делайте этого. Анонсы - это опасная игра.

Лучший подход к достижению (возвращению) лидирующей позиции можно выразить одним словом: непреклонность.

Если конкуренция - это состязание, то зрители это клиенты. Они любят хорошую борьбу и имеют право указывать большим пальцем вверх или вниз.

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

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

Я не хочу сказать что запускаться так надо, нет, ни в коем случае. Просто нам повезло.

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

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

№11 Идете бок о бок с конкурентами? Избегайте перестрели отличительными особенностями

Существует два принципиальных метода избежать перестрелки отличительными особенностями:

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

Как же назвать ситуацию когда вы не отстаете от конкурента? Вы позади? Или вы идете бок о бок с конкурентом? 

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

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

№10 Вы в одиночестве? Рынка без конкуренции не бывает.

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

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

Конкуренция

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

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

Целые поколения "неспособных к командной работе" были уничтожены на корню "способными к командной работе".

Я очень редко видел людей, и ни разу не видел команд, которые представляли из себя "стаю рычащих волков". Появляется страх что могу и не увидеть.  Обычный разработчик- это человек который сидит и что то делает, а что делает не понятно. Нет огонька в глазах, нет бурлящей атмосферы. 

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

№9 Будьте властью, но не фигурой власти

В отношении власти в команде цель следующая: сделать властью каждого члена команды. Вы должны стремиться к тому, что бы команда имела власть как индивидуальную, так и коллективную.

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

 

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

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

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

Цель - наделить каждого члена команды максимально полной властью, а не загребать власть под себя.

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

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

Послание команде звучит так: "Есть задача которую надо решить. Она касается создания ПО. Она не имеет отношения к следующим проблемам: кто и какие принимает решения, кто и за что вознаграждает, кто и за что наказывает".

Дух группы

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

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

Основной принцип следующий: если вы не можете понять что у вас происходит в команде, посмотрите на ПО.

Ключ к созданию качественного ПО - постоянное поддержание контакта с "духом команды".

Для более детального изучения этой темы обратитесь к книге "Программируем командный дух".  Вы также можете присоединиться к группе изучения этой книги: Agile Study Group: Программируем командный дух

Подготовленно по книге

"Правила разработки программного обеспечения" Джим Маккатри, Мишель Маккарти

№8 Используйте руководителей проектов

Руководители проекта:

• возглавляют определение успешного проекта
• возглавляют распространение видения проекта
• возглавляют движение проекта к гарантированной поставк продукта

Эффективный руководитель проекта - это совсем не то, что подчас думает о себе номинальный руководитель проекта.

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

Прочитав эти строки первый раз, я был возмущен до глубины души. Как не имеет власти? Как не будет писать спецификации? В то время, все мои представления были связаны именно с тем, что руководитель отдела разработки - это человек который говорит каждому члену команды,  что он должен делать и как он это должен делать. Мой девиз был примерно такой: "Если вы считаете что программирование это творческая работа, тогда нам с вами не по пути". Звучит ужасно, неправда ли? Потом случай свел меня с Денисом (Денис Миллер), и я начал читать книги и учится. Кстати пользуясь случаем, хочу сказать ему спасибо (в качестве рекламы ссылка Study Group).  

А что если подумать? Кстати вот отличный ролик, что бы хорошо думалось Снежинка

Управление проектом является технической задачей. Есть два аспекта технического мастерства:

• технология, используемая при создании проекта
• технические аспекты лидерства при создании ПО

Руководитель проекта должен владеть многими искуствами. Он должен уметь

• уговаривать
• содействовать
• внушать вдохновление
• требовать совершенства и эффективной работы
• должен знать все входы и выходы  для выпуска ПО в срок
• должен применять лучшие практические методы
• должен быть представителем команды для руководства

Руководитель проекта является сердцем разработки ПО.

Подготовлено по книге 

"Правила разработки программоного обеспечения" Джим Маккрти, Мишель Маккарти