<<
>>

Смена курса

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

• Собирайте факты, но не перестарайтесь с их анализом

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

С другой стороны, постарайтесь не попасть в ловушку «паралича анализа».

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

• Вовлекайте в обсуждение проблемы других специалистов

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

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

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

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

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

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

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

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

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

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

<< | >>
Источник: Эд САЛЛИВАН. ВРЕМЯ — ДЕНЬГИ Создание команды разработчиков, программного обеспечения. 2001

Еще по теме Смена курса:

  1. Часть II Глобализация и смена парадигм в политической социологии
  2. 5 СМЕНА РОЛЕЙ
  3. СМЕНА ИГРЫ
  4. 5 .1. Смена образовательной парадигмы
  5. § 5. Запугивание, маскарад, смена профессии
  6. Луна "без курса"
  7. ЦЕЛЬ И ЗАДАЧИ КУРСА
  8. Программа курса «Гражданское право (общая часть)»
  9. Программа курса «Гражданское право (особенная часть)»
  10. 1. Предмет и система курса гражданского права