Время — деньги. Создание команды разработчиков программного обеспечения
Шрифт:
Из собственного опыта
В NuMega группа технической поддержки часто используется для подстраховки при разработке программ. В службе поддержки компании много ярких личностей, которые хотели бы повысить свой опыт разработчиков. Мы дали им возможность поработать над созданием самых настоящих программ, а они в свою очередь помогли группе разработчиков не выбиться из плана. Естественно, такая помощь часто означала для членов группы технической поддержки сверхурочную работу, но они почти всегда были готовы потратить несколько лишних часов, чтобы помочь разработчикам
• Нанимайте консультантов и исполнителей
Следует подумать о найме консультантов и исполнителей для выполнения чётко определённой и относительно краткосрочной работы. Ваша задача — закрыть критические участки проекта, на которые не хватает собственных кадров. Но остерегайтесь использования консультантов в качестве ведущих специалистов, так как они, скорее всего, покинут группу по завершении проекта.
• Лучше отказаться от части функций, чем расширятъ план
При необходимости подумайте об отказе от некоторых функций программы. Если приоритетные функции определены и их реализация запланирована на ранних этапах работы над проектом, вполне можно отказаться от ряда второстепенных функций. Прежде чем решиться на расширение плана, рассмотрите возможность исключения ряда функций второго или третьего плана. Отказ от реализации некоторых функций позволяет разгрузить все группы и снизить риск срыва. Расширение плана лишь повышает риск срыва даты выхода продукта. Тривиальное добавление новых функций, не имеющих значения для успеха ПО — не самое мудрое решение: важнее вовремя выпустить продукт, чем реализовать все второстепенные функции.
Есть хороший способ решить, вносить или не вносить изменение. Для этого нужно спросить у себя: «А что, если я не стану этого делать?» Такие вопросы особенно полезны в борьбе с так называемым «дрейфом функций», который может существенно прибавить работы группе. Однако зачастую изменения вносят без солидного технического или экономического обоснования. Изменение может воплощать хорошую идею, но она может не стоить того риска, которому подвергает весь проект. Конечно, должен быть определённый уровень совершенствования функций, но не до такой степени, чтобы проект был захлестнут потоком мелких изменений. Всегда спрашивайте себя: «А что, если я не стану этого делать?» Это заставит сравнить цену отказа от изменения с ценой его реализации.
Вот примеры хороших вопросов, на которые нужно ответить при поступлении предложения о реализации новой функции.
• Какая часть прибыли будет потеряна, если отказаться от реализации новой функции?
• Скольким клиентами будет полезна новая функция?
• Не сорвёт ли (или подвергнет риску) новая функция срок выхода продукта?
• Снизится ли конкурентоспособность продукта без этой функции?
• Какому риску подвергнется качество продукта при отсутствии новой функции?
• Какое влияние окажет новая функция на использование программы, документацию, а также на процессы её сборки и установки?
Это не означает, что нужно отказаться от изменений вообще, — просто всегда нужно быть уверенным, что выгода от изменения намного больше расходов на её реализацию.
Решать проблемы нужно как можно скорее, не позволяя им долго оставаться открытыми. Так или иначе, решение должно быть принято. Прийти к согласию — ваша задача, но помните, что она не всегда достижима. Кроме того, консенсус означает не единодушное согласие, но согласие большинства. Если после сбора информации и её анализа согласие все ещё не достигнуто (т.е. существуют разные мнения) абсолютно необходимо, чтобы менеджер проекта или один из его ведущих специалистов принял решение самостоятельно. Не откладывайте это и не проявляйте нерешительность — здесь нужна сильная рука лидера. Группе необходимо решение для продолжения работы, задержка с его принятием снижает мотивацию группы, и можно упустить благоприятный момент. Помните: лучше принять неверное решение, чем долго тянуть с его принятием и так никогда не узнать, что правильный выбор был совсем рядом.
Несмотря на самые благие намерения и усилия по планированию, порой приходится увеличивать темп работы, чтобы уложиться в сроки или отреагировать на изменившиеся условия. На первых порах сверхурочная работа требуется для решения большинства проектов; такая ситуация также типична для большинства проектов, которые нужно завершить в сжатые сроки, но бывают случаи, действительно требующие особой самотдачи, и речь здесь идёт не просто о паре лишних часов в неделю. Прежде чем принять решение об увеличении нагрузки на группу, нужно знать, когда это уместно и как делать это эффективно.
Менеджеру проекта и ведущим специалистам очень важно знать, когда нужно проситъ команду или её участника о дополнительных усилиях. Чтобы эта просьба нашла отклик, её причины должны быть обоснованы, а задачи — ясны каждому. Дополнительная работа потребуется, если необходимо следующее:
• Завершить очередной этап в срок
Если очередной этап работы близится к концу и при этом есть ощущение, что можно не уложиться в сроки, нужно начинать сверхурочную работу уже сейчас, а не позже. Как сказано выше, не следует дожидаться начала следующего этапа, чтобы обнаружить проблемы с завершением текущего. Если чувствуете, что план может быть сорван, лучше приложить дополнительные усилия раньше, чем позже.
• Наверстать упущениое
Если не удалось уложиться в срок при выполнении промежуточного этапа работы, упущенное придётся навёрстывать. Помимо этого, нужно завершить следующий этап в срок. Если вы всерьёз хотите вовремя закончить работу над проектом, приложите дополнительные усилия уже сейчас.
• Справиться с возросшей конкуренцией
Если на рынке произошли серьёзные изменения, чтобы достигнуть успеха или просто не быть вытесненным конкурентами, реализацию проекта придётся ускорить. При этом, возможно, придётся добавлять новые функции к продукту или ужать план на месяц. Это потребует от всей группы полной самоотдачи.
Прежде чем просить кого бы то ни было посвятить проекту дополнительное время, убедитесь, что ваша просьба обоснованна. Постоянно прося команду об изменении графика работы или штурмуя каждую проблему работой в сверхурочное время, вы быстро исчерпаете продуктивность и эффективность команды. Нельзя заставлять людей слишком долго и слишком много работать сверхурочно. Этот подход следует использовать для навёрстывания упущенного или для адекватной реакции на внешние события, но нельзя делать сверхурочные частью нормального графика работы.