Продолжение. Начало "Молоко на губах"
То, что вы могли видеть в фильме "Хакеры"- мелкий детский лепет. Мир IT гораздо интереснее и заковырестее. Как делаются программы? Кем лучше быть- программистом или менеджером? Чтобы понять ответы на эти вопросы прочтите очередную главу этого столь долго затянувшегося приступа графомании.Попрошу так же учесть, что на практике процесс производства программного обеспечения может весьма сильно отличаться от описанного. Здесь приведен некий средний вариант процесса.
Ранее были рассмотрены различные специализации, и было упомянуто, что у прикладных программистов есть более узкая специализация: разработчик игр, разработчик интерфейсов, разработчик серверных систем и т.д. К тому же, описание специализаций, не привязанных к конкретным должностям, не вписанных в технологическую цепочку производства программного продукта, воспринимается запутанно и мало что проясняет. Поэтому в этой части статьи будет дано описание типовой технологической цепочки производства программного продукта. Наиболее полно данная цепочка реализуется в софтверных компаниях. В отделах АСУ она значительно урезана. Я буду опираться в своем описании на полную, развернутую технологию производства ПО. Бюрократическую сторону (подписание договоров и пр.) производства я буду, по возможности, опускать.
Все начинается с заказа. Это может быть внутренний заказ отделу АСУ, или внешний заказ от клиента, или разработка коробочного продукта. Для больших внешних заказов клиент может провести конкурсные торги. После того, как клиент проявил интерес к предложению от фирмы и готов далее сотрудничать или для коробочной продукции принято решение о целесообразности ее разработки, заказ на разработку передается в IT-отдел, начальнику IT-отдела. Начальник отдела изучает информацию:
- о клиенте,
- о его заказе,
- о приблизительной стоимости проекта "на глаз",
- оценивается "крупность" клиента ("потянет" ли он свои "хотелки", т.е. насколько серьезно его воспринимать),
- о перспективности клиента (насколько вероятно, что в будущем он еще раз обратиться с заказом),
- для коробочной продукции оценивается объем рынка и его динамичность.
Основным документом проекта является техническое задание (ТЗ). Именно оно определяет объем работы, на основании его формируется бюджет проекта, составляется план работ. Любые претензии клиента по проекту будут всегда рассматриваться через призму технического задания, что сделано, что не сделано. Поэтому, если вы, как программист, участвуете в проекте, то никогда не основывайтесь в своих действиях на устной договоренности! В первую очередь, Вас должно волновать выполнение ТЗ, а уж потом все остальное. Составлением ТЗ занимается аналитик. Аналитик вместе с руководителем проекта изучает задачу во всех подробностях и формализует задачу. Если задача по своим масштабам большая или при ее решении есть ряд технологических трудностей, то к составлению ТЗ привлекаются системный архитектор и ведущий программист. Часто их на данном этапе используют для подстраховки, т.е. задача не сложная, но мало ли что – лучше лишний раз переспросить, проконсультироваться, чем потом залатывать прорехи в ТЗ. Системный архитектор подскажет, как лучше решить задачу, сделает примерный набросок архитектуры системы. Результатом его работы будет эскизный проект, обобщенная структурная и функциональная схема программы. Ведущий программист укажет, с помощью каких технологий лучше реализовать предложенную архитектуру проекта, а также подскажет руководителю проекта кто из программистов лучше подойдет для реализации той или иной части проекта. Результатом работы ведущего программиста при составлении ТЗ является частичное техническое задание (ЧТЗ). Техническое задание утверждается начальником отдела и подписывается заказчиком вместе с планом выполнения работ.
После формализации задачи, подписания ТЗ, формирования бюджета проекта руководитель собирает команду, которая будет заниматься реализацией проекта. Для получения людей в свой проект руководитель дает заявку координатору проектов (если в организации нет должности координатора проектов, то начальнику IT-отдела). Координатор оценивает наличие свободных в данный момент программистов или тех, у которых нагрузка по текущим проектам невысокая и утверждает окончательный список команды проекта.
К тому времени руководитель проекта занимается выделением необходимых технических ресурсов для реализации проекта. Возможно, потребуется приобретение дополнительных компьютеров, расширения штата имеющих программистов из-за нехватки имеющихся работников и т.п.
Заявка на приобретение дополнительной техники подается в отдел системного администрирования. Туда же подается заявка на создание необходимых для выполнения проекта сетевых ресурсов (создание рабочей группы в домене, рабочей папки, нового проекта в системе контроля версий и прочее). Старший системный администратор обрабатывает заявку на закупку техники. В соответствии с принятой политикой закупок техники на предприятии по заявке выбирается конкретная конфигурация ЭВМ, добавляется требуемое оборудование для подключения техники к локальной информационной компьютерной сети организации и осуществляется закупка. Системные администраторы осуществляют настройку компьютеров и установку ПО:
- «сетевики» прокладывают локальную сеть.
- Специалисты Help-desk настраивают компьютеры.
- Администраторы сервисов прописывают новые компьютеры в сетевых сервисах, создают под проект сетевые ресурсы.
Итак, у проекта есть руководитель, подготовлена техника, выделены люди, недостающие наняты. В дело вступает системный архитектор. Он уже ранее подключался к проекту при составлении ТЗ. Теперь его задача – плотно курировать проект. По обобщенным структурным и функциональным схемам составляется детализированные структурные и функциональные схемы, которые до мельчайших подробностей обсуждаются с ведущим программистом проекта. Ведущих программистов в проекте может быть несколько. Это делается в том случае, когда проект очень большой и разбивается на части. Реализация каждой части проекта поручается отдельному ведущему программисту. Ведущий программист проекта разбивает проект на отдельные задания и выдает их программистам проекта для написания самостоятельных модулей программы. Выполненные задания сдаются программистами своему ведущему программисту, который осуществляет сборку модулей и компилирует проект в целом (как еще говорят, выкладывает билд проекта).
На основе билда инсталляторы (тоже разновидность узко специализированного программиста) готовят инсталляционный пакет. Пакет попадает на тестирование к тестировщикам. Тестировщики формируют список ошибок с подробным описанием действий, при которых возникла ошибка. Ведущий программист назначает того, кто устранит ошибку (т.к. ведущий программист по описанию ошибки примерно представляет, в каком модуле произошла ошибка, и знает, кто этот модуль делал).
Параллельно работе над программным кодом идет разработка документации по программе, пишутся help-файлы. Этим занимаются "течрайтеры" (tech. writer), т.е. технические писатели в переводе.
В проекте выделяются специалисты по интерфейсу, которые прорабатывают графический интерфейс взаимодействия программы с пользователем. Разрабатываются экранные и печатные формы. Отслеживается, чтобы все формы имели единый стиль.
Код программы, написанный разными программистами, должен быть единообразен, читаем легко, что облегчит в дальнейшем его повторное использование. Для этого код проверяет отдел контроля качества.
Стажерам, как разнорабочим, в проекте поручают выполнение мелкой работы: съездить к заказчику и установить модуль, изменить у заказчика настройки, сбегать к тестировщикам, чтоб они конкретно показали, где у них ошибка "выскочила". Нередко стажерам даже отдельного рабочего места не выделяют.
Постоянно идет согласование работ с заказчиком. По плану ему сдаются промежуточные этапы работ. По ходу реализации проекта производится уточнение и ТЗ может быть скорректировано. Это оформляется дополнительным приложением. По мере продвижения работ программистам часто приходится возвращаться к уже написанным модулям и изменять их либо по требованию заказчика, либо по требованию отдела качества, либо из-за выявленной ошибки при тестировании, либо при решении руководителя проекта, системного архитектора, ведущего программиста изменить что-то в проекте. Часто используется итерационный способ разработки. Это когда в программе реализуется сначала основная функциональность, а потом по мере уточнения требований заказчика и корректировок в проекте выполняются более мелкие проработки в программе.
Чувствуете, как все непросто получается? Программисты, "течрайтеры", интерфейсы, инсталляторы, тестировщики, отдел качества – и все делают работу параллельно, всех их надо вместе свести, состыковать. Вот она, адская работа руководителя проектов! В помощь руководителю проектов разработаны различные методологии проектирования. Однако чаще эти методологии еще больше затрудняют работу. Слишком много вокруг них маркетинговой мишуры. Начинающим выстраивать свою карьеру программистам я рекомендую полностью игнорировать в объявлениях о работе требование знать методологии проектирования RUP и т.п. Если вакансия вам нравиться, а там стоит такой пунктик, и вы не знаете вообще никаких методологий, то все равно смело шлите свое резюме. Скорее всего, сам работодатель за маркетинговой болтовней до конца не понимает и не знает этих методологий. Просто так сейчас модно.
Когда программа закончена, наступает следующий этап- сдача проекта. Заказчику предоставляется финальный релиз программы и, если все выполнено в соответствии с ТЗ и у заказчика нет претензий к исполнению заказа, то подписывается акт выполненных работ. Очень часто на этом этапе заказчик предъявляет множество замечаний и новых "хотелок". Вот тут четкое следование ТЗ играет свою главную роль! Если все выполнено строго по ТЗ, то, как правило, заказчик подписывает акт. В противном случае в дело вступают юристы. Это еще не все! В крупных организациях неповоротливая бюрократическая машина может задержать оплату выполненных работ надолго. Мне известны случаи задержки на 2 года! Все это время руководитель проекта должен держать ситуацию на контроле. Проект только тогда считается законченным, когда по нему будет произведен полный расчет с заказчиком, всем участникам проекта выплачены премии, а дело сдано в архив.
Ну, как? Сложно? Интересно? Вот такая вот она, профессия IT!
