<Текст статьи>

27 способов узнать, что ваш проект разработки ПО обречен

Иногда бывает непросто при работе над проектом вовремя остановиться и взглянуть на проделанное со стороны. Здесь важно не упустить момент и вовремя понять, что все потеряно и не осталось абсолютно никаких шансов вытянуть ЭТОТ проект и довести его до успешного логического завершения. А ведь у вас был шанс заранее спрогнозировать ситуацию и осознать, что начатое дело было обречено на провал.

Эстер Шиндлер

Несмотря на все усилия, направленные на то, чтобы обеспечить успешную реализацию каждого программного проекта, над некоторыми из них с самого начала​ казалось, висит проклятие. После бесед со специалистами мы выявили 27 признаков ( увы, все они плоды горького опыта), свидетельствующих о том, что разработка ПО движется в никуда:

* В течение нескольких месяцев название проекта трижды менялось.

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

* Определять требования начинают только через четыре месяца после начала разработки.

* Недавно приглашенный директор по научным исследованиям и разработкам с гордостью докладывает на заседании совета директоров о том, что проект завершен на 99%, и это произошло на полгода раньше установленного срока. Одновременно он заверяет присутствующих, что программное обеспечение можно поставлять клиентам, минуя этап бета-тестирования.

* Будучи веб-разработчиком, вы открываете архивный файл с документами HTML, которые клиент подготовил для создания сценариев сайта и последующей их интеграции с веб-приложением. И здесь обнаруживается, что все клиентские HTML-документы на самом деле представляют собой файлы Microsoft Word, сохраненные в формате HTML.

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

* Согласно полученной директиве вам предстоит разрабатывать 64-разрядное приложение на 16-разрядной платформе.

* Исполнитель не понимает смысла спецификаций, но проектирование не останавливается. Служба контроля качества не имеет представления о том, как следует проводить испытания, однако "тестирование" продолжается.

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

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

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

* К вам обращаются с просьбой перенести свой проект из среды Windows на платформу MS-DOS.

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

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

* Составление исполнителями по собственной инициативе отчетов о ходе выполнения работ и состоянии объектов рассматривается как нарушение дисциплины и субординации.

* Новый ИТ-директор избавляется от всех, кто поддерживает тесные контакты с сотрудниками его бывшей организации.

* Проект невозможно обозреть, и имя ему "Айсберг". Или же компания в третий раз пытается реализовать нечто под кодовым наименованием "Феникс". Порой вам и самому уже не верится, что это нечто сможет-таки возродиться из пепла.

* Продуктом недовольны даже пользователи, получающие бесплатную версию.

* Руководитель критически важного проекта (который должен приносить компании 80% ее доходов) на протяжении трех месяцев знакомится с выбранной технологией и одновременно обучает четырех новых разработчиков. А до сдачи проекта остается всего три месяца.

* Вы приходите к выводу, что руководство должно было настоять на проверке определения интерфейсов после утверждения первого варианта кода.

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

* Службе технического контроля отводят на тестирование всего три недели (в условиях, когда реализация проекта длится уже полгода). Или же ее представителям заявляют, что срок сдачи уже определен и зафиксирован, а значит, весь функционал к этой дате должен быть проверен в полном объеме.

* Руководитель проекта решает опробовать модную методологию гибкого проектирования, чтобы "сэкономить время".

* Давным-давно, еще до появления сотовых телефонов и повсеместного доступа в Интернет, вы получали нагоняй от нового руководителя проекта, после того как возвращались с трехдневной конференции региональных ИТ-директоров. И за что же? За то, что не отвечали на отправленные руководителем проекта электронные письма (которые, кстати говоря, до вас так и не дошли) и не обновляли "панель состояния проекта", о существовании которой ничего не знали.

* Руководство решает потратить на проект сумму, в 50 раз превышающую его реальную стоимость. Затем менеджеры соглашаются с дистрибьюторами аппаратного обеспечения, утверждающими, что в оборудование придется вложить денег в 2 раза больше, чем в ПО. А в это время секретарша покупает готовый ПК и CD-ROM, на котором записано несколько новых программ офисной автоматизации. В результате реализацию всего проекта она успевает осуществить за обеденный перерыв. (Справедливости ради,такое достижение следует признать несомненным успехом.)

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

* Спонсор проекта призывает всех творчески относиться к делу. А происходит это на фоне сокращения на 20% численности участников проекта и после того, как вам выдают оборудование, списанное было в утиль, заявляя, что теперь у проекта имеется новая хостинговая платформа.

Итак, мы привели список возможных проблем, составленный по итогам опроса 12 разработчиков ПО и специалистов в области ИТ. К сожалению, он этим перечнем не исчерпывается. И мы надеемся, что вы дополните его своими замечаниями.

[фото]