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

Эд Йордон — редактор журнала Cutter IT Journal, издаваемого корпорацией Cutter Consortium. С ним можно связаться по адресу www.yourdon.com

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

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

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

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

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

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