Время - деньги. Создание команды разработчиков программного обеспечения

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

• Используйте помощь других групп при разработке и тестировании

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

Из собственного опыта

В NuMega группа технической поддержки часто используется для подстраховки при разработке программ. В службе поддержки компании много ярких личностей, которые хотели бы повысить свой опыт разработчиков. Мы дали им возможность поработать над созданием самых настоящих программ, а они в свою очередь помогли группе разработчиков не выбиться из плана. Естественно, такая помощь часто означала для членов группы технической поддержки сверхурочную работу, но они почти всегда были готовы потратить несколько лишних часов, чтобы помочь разработчикам и приобрести дополнительный опыт. Кроме того, это возможность сделать карьеру. Благодаря полученному опыту и оказанной ими помощи, участники группы технической поддержки завоевали уважение разработчиков и энергично продвигались на должности разработчиков. Это ещё одна причина нанимать стоящих людей на любую должность.

• Нанимайте консультантов и исполнителей

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

• Лучше отказаться от части функций, чем расширятъ план

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

Задавайте верные вопросы

Есть хороший способ решить, вносить или не вносить изменение. Для этого нужно спросить у себя: «А что, если я не стану этого делать?» Такие вопросы особенно полезны в борьбе с так называемым «дрейфом функций», который может существенно прибавить работы группе. Однако зачастую изменения вносят без солидного технического или экономического обоснования. Изменение может воплощать хорошую идею, но она может не стоить того риска, которому подвергает весь проект. Конечно, должен быть определённый уровень совершенствования функций, но не до такой степени, чтобы проект был захлестнут потоком мелких изменений. Всегда спрашивайте себя: «А что, если я не стану этого делать?» Это заставит сравнить цену отказа от изменения с ценой его реализации.