Старт проекта

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

 

Согласование ТЗ 

В процессе выбора процессора мы остановились на процессоре МС-24 фирмы "Элвис". У него были параметры, удовлетворяющие заказчиков - тактовая частота и рабочий диапазон температур, набор встроенной периферии. И, конечно, главное - отечественная разработка. С другой стороны, заказчику не хотелось терять наработанные за десятки лет алгоритмы управления двигателем, созданные для другого процессора, Motorola 68332. История с американским проектом А-7 (попытка полного переписывания программного обеспечения для самолета А-7, завершившаяся неудачей) была известна всем, и никому не хотелось повторять этот печальный опыт. Тогда мы вместе с заказчиком приняли простое решение - раз нельзя изменить старое ПО под новый процессор, то надо спроектировать новый процессор, который может работать со старым ПО. Собственно, нужно спроектировать функциональные устройства этого процессора, на языке описания аппаратуры VHDL, по сути, заново создав процессор 68332 в ПЛИС (программируемая логическая интегральная схема) и, таким образом, использовать имеющиеся алгоритмы.

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

 

Команда проекта

Руководитель (я)

Тимлид-архитектор

Программисты прикладного ПО - 2 человека

Программисты VHDL - 5 человек, 3 - из другого подразделения Института, 2 оутсорсера из г.Коврова

Инженер-электронщик

Монтажник

 

Аппаратная часть системы

В результате проектирования и переговоров родилась такая архитектура аппаратной части системы:

 

Functional_sch

 

Аппаратной ее можно было назвать достаточно условно, поскольку основная функциональность, ноу-хау системы заключалось в ПЛИС, которая создавалась программно, на языке описания аппаратуры VHDL. Те же самые программные модули, то же самое обеспечение их взаимодействия между собой, и увеличенный, по сравнению с обычным ПО, объем тестирования - ошибка могла привести к поломке устройства у заказчика, а не к падению программы, как на обычном PC. А если еще учесть тот факт, что конечный заказчик находился на другом конце страны... 

 

Программное обеспечение

К программному обеспечению контроллера относятся:

1. Тестовое ПО для проверки программной и аппаратной части контроллера. Забегая вперед, скажу, что на тесты пришлось около 30% трудоемкости создания всей системы.

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

3. Драйвера для периферийных устройств. Несмотря на то, что большинство протоколов обмена были реализованы аппаратным образом (на VHDL), над драйверами тоже пришлось поработать. Процесс разработки драйвера происходил так: вначале писался программный драйвер, а затем его функции постепенно, по мере отладки,  переносились в аппаратуру. 

4.Монитор-планировщик реального времени. По сути - мини-ОС, но назвать ее таким образом  в ТЗ означало бы лавинообразное увеличение согласующих документов. Он представляет собой систему запуска фиксированного числа задач (с фиксированными приоритетами) на выполнение в строго заданные периоды времени (все задачи периодичны).

 5. Целевое ПО (алгоритмы управления двигателем). Заказчик писал их сам, вернее, использовал имеющеся с минимальными изменениями.

 

Подбор команды

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

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

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

Хуже всего ситуация обстояла с техническими писателями - разработка делалась для госзаказчика, объем документации составил свыше 30%. Пришлось искать людей на оутсорсинге,  т.к. хороший технический писатель - это человек 50+ лет, который очень неохотно покидает насиженное место работы. Поэтому я был вынужден часть работ по документированию перекладывать на разработчиков, что привело к негативным последствиям - об этом позже. 

 

Бюджет проекта

Бюджет проекта считался просто - из диаграммы Ганнта в MS Project было получено рабочее время разработчиков и руководителя, оно умножалось на соответствующие почасовые рейты, добавлялись материальные затраты, раздельно учитывались риски разработки и материальные, добавлялась маржа и выдавалась итоговая сумма.

 

Особенности проекта

Сложностей было много и начались они еще перед подписанием контракта. Прежде всего, заказчик не хотел платить за проект запрашиваемую сумму. Я показал руководству свои расчеты, подчеркнув, что это лучший вариант, и отдельно - 20% на риски (тогда я был еще большим оптимистом). После чего предложил принять решение, откуда возьмутся эти недостающие 20%, которые на риски как раз и приходились. Руководство согласилось взять риски на себя, поскольку осознавало, что влезть в прибыльную нишу авиационной электроники просто так не удастся.

Следующей проблемой была работа с госзаказчиками. Как известно людям, работавшим с проектами в интересах государства, деньги на оплату таких проектов перечисляются один раз в году, в конце года, а деньги разработчикам надо платить в течение всего периода времени, причем регулярно. Наш Институт с численностью 600 человек тоже имел свои правила, одно из которых гласило - кроме как на зарплату разработчикам, ни рубля не может быть перечислено на проект, по которому не заключен контракт с авансом. Соответственно, возникла проблема - сроки закрытия первого этапа поджимали, а денег на изготовление печатной платы (40 000р, плата была довольно сложная) не выделялось. Тогда я оговорил письмом к финдиректору, поставив для страховки еще несколько человек в СС, что я отдаю 40000р своих, но мне их возвращают с заключением контракта. Финдиректор согласился, и этап в срок все-таки был сдан. Деньги мне вернули через несколько дней - спонсор проекта, бывший в копии, возмутился и поднял шум. 

Как выяснилось позже, наш продакт-менеджер под давлением заказчика согласился на внесение в контракт военной приемки, но не уведомил об этом нас.  Мы узнали об этом только в процессе сдачи первого этапа. Тогда же военпред, совершенно справедливо с его стороны, потребовал реализовать понятие "Комплект документации" так, как оно описано в ГОСТ 34.201-89 на технический проект, а это повлекло за собой дополнительно три человеко-месяца трудозатрат только на документацию, плюс время на сдачу проекта по военным стандартам (кто сдавал - тот знает, какую дополнительную кучу  бумаг надо подготовить). Ничего страшного, если внесение в контракт военной приемки было бы увязано с увеличением цены и сроков, но это увязано не было.

Еще одним риском, который невозможно было учесть при планировании, стала среда программной разработки IDE, поставлявшаяся с процессором. Несмотря на немалую стоимость, от ее использования пришлось отказаться - обилие ошибок и падений в процессе отладки не позволяло работать сколь-нибудь продуктивно. Тогда мы взяли open-source IDE Eclipse, и, добавив к нему имеющиеся в комплекте поставки gcc и gdb, заставили его работать с процессором. После этого стало возможным разрабатывать и отлаживать программное обеспечение.

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

 

Архитектурное проектирование

Архитектуру контроллера создавал программист - архитектор появился позже. Хотя это и на первый взгляд выглядит странно, но на самом деле за этим стояла своя философия. Поскольку успех устройства зависит от того, как нему отнесутся программисты заказчика - а именно для них делалось устройство - логично, если устройство будет оптимизировано именно с точки зрения программиста. Соответственно, было проведено более десятка совещаний с программистами заказчика, и итоговая архитектура их вполне устроила. 

Например, мы освободили програмиста от работы с регистрами периферийных устройств путем создания в ПЛИС конечных автоматов, которые работали с регистрами сами, без участия программиста. Для программиста, например, контроллер последовательного порта был устройством ввода-вывода с двумя адресами, в один он писал данные, из другого считывал, по приходу прерывания, без каких-либо предварительных настроек - те программисты, кто работал с чипами, смогут оценить эту особенность. Кроме того, мы разгрузили шину процессора от устройств с медленной скоростью обмена - так, например, скорость доступа к памяти и к контроллеру интерфейса MIL-STD1553 различались в 50 раз - и подключили их напрямую к контроллеру периферии, тем самым значительно увеличив как пиковую, так и общую производительность системы. Если обобщить, мы создали аналог "Южного моста", как в чипсетах для РС.

  

Ход выполнения

Как и в большинстве проектов, в начале мы обгоняли график, с течением времени дополнительные требования сделали свое черное дело, и в конце проекта мы начали отставать на месяц. Для контроля прогресса проекта использовался MS Project, график составлялся в клиенте и выкладывался на Project Server, при этом исполнители заполняли рабочее время через Project Web Access. Вначале я пытался требовать внесения трудозатрат ежедневно, но потом, поняв полную бесперспективность этой затеи, перешел на заполнение часов по пятницам.

Достаточно сложно было приучить всех, и в первую очередь оутсорсеров пользоваться SVN, а не присылать результаты в электронной почте. Второй проблемой с версионным контролем было то, что разработчики заполняли комментарии при коммите новой версии через раз – к этому мне их так приучить и не удалось. Третья проблема - они клали документы не туда, приходилось смотреть логи и перемещать документы в требуемое место.

С командой ПЛИС возникли проблемы. Дело в том, что все имеющиеся у нас в Институте ресурсы были загружены, что называется, под завязку. Абсолютно без проблем было получить специалистов высокого класса на несколько часов, проблемой было получить их на несколько часов каждый день в течение трех месяцев. Т.е. не было проблем с архитектурным проектированием, была проблема с реализацией архитектуры.

Я пошел следующим путем - организовал в Институте обучение языку VHDL. Руководство давно хотело это сделать, так что идея обучения нашла самое горячее одобрение. На второй день обучения я спросил у лектора, может ли он порекомендовать кого-либо для решения вот таких задач (ТЗ для ПЛИС на тот момент у нас уже было). Как я и предполагал, порекомендовать он смог. Себя и еще одного человека. Договорились о почасовом рейте, оплате проезда (он жил в Коврове) - и работа началась. Вначале все было хорошо, шли даже с опрежением графика. Потом выявилось отставание, которое начало увеличиваться с течением времени. Резко снизилось качество кода, код стал все чаще валиться на тестах. Я не стал надеяться на чудо и поговорил с оутсорсерами. Как я и предполагал, у ребят появился свой проект, который они делали основное время. Когда я попросил их выбрать один из двух, они выбрали не наш. Я выразил сожаление, оплатил им все заявленное время и расстался с ними, сказав спасибо - без иронии. Хотя многие мне советовали не оплачивать явный брак, я решил, что сэкономленные 500$ не стоят того, чтобы остаться с написанным оутсорсерами кодом один на один, и оказался прав - к ним пришлось еще несколько раз обратиться.

Снова встала проблема поиска оутсорсеров, но во второй раз задача стала сложнее - проект уже шел вовсю, и каждый час, прожитый без разработчиков ПЛИС, нес большие убытки. Пришлось обратиться за помощью к спонсору проекта, попросив его поискать ведущиеся в Институте проекты разработки сферических коней в вакууме. Такой проект быстро нашелся, причем он, как обычно, занимал лучшие ресурсы. Эти ресурсы не сразу согласились перейти в наш проект. Но применяя кнут и пряник (угрозу закрыть их проект совсем и обещая премии в случае успеха нашего), спонсор добился того, чтобы программисты работали по 4 часа в день на свой проект и 4 - на наш. Разумеется, я не строил иллюзий по поводу того, сколько часов они будут реально работать на наш проект, поэтому посидел с ними пол-дня, составил график работ, заложил в него риски и в дальнейшем требовал выполнения этого графика. Если график срывался, я устраивал разбор полетов и докапывался до причины - это всегда было неотработанное время. После нескольких таких разборов программисты смирились с неизбежным и уже посвящали нашему проекту если и не все запланированное время, то, по крайней мере, достаточно, чтобы оставаться в графике. 

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

 

Управление требованиями

Будучи наученным прошлым опытом, и прочитав "Принципы работы с требованиями к ПО" Леффингуэла-Уидрига,  я ввел в проекте с самого начала управление требованиями. Поскольку это был мой первый проект заказной разработки, а у заказчика это тоже был первый проект с внешними разработчиками, никто из нас не знал, что можно делать, а что нет. Я сделал так: организовал отдельную группу на трекере JIRA, написал инструкцию по работе с ней и сказал заказчику, что все запросы на изменения я буду принимать исключительно через трекер. Можно присылать письмом, но я все равно не буду на него отвечать, а  скопирую эту информацию в трекер и рассмотрю запрос там. Пришлось повозиться, но в конце концов я добился единого канала внесения изменений. Участникам команды я строго запретил реагировать на письма и телефонные звонки с просьбой об изменениях, пересылая просителей ко мне (потом мне сказали, что заставить госзаказчика работать через трекер невозможно в принципе, но поскольку я не знал об этом заранее - все получилось). И это дало свои плоды, как в долгосрочной, так и в краткосрочной перспективе. В краткосрочной перспективе поток изменений, который обычно является основным риском краха проектов, был взят под контроль и уменьшен до приемлемого уровня. В долгосрочной перспективе, после завершения проекта и перед подписанием нового контракта, мы имели на руках задокументированную информацию об изменениях, реальные трудозатраты на внесение изменений (они вносились в трекер) и попросту добавили их в стоимость следующего контракта. Заказчику на наши аргументы возражать было трудно - вот все дополнительные затраты лежат на столе, на трех листах, с датами, трудозатратами, фамилией инициатора внесения и причиной.

 

Завершение проекта

Основное время работы над проектом у нас не возникало каких-либо трудностей, кроме описанных выше - они вызывались реализацией непредвиденных внешних рисков, а такие вещи неопасны, они только сплачивают команду. Тактика использования суперразразработчиков в проекте оправдывала себя на этапе разработки, но на этапе сдачи и документирования возникли проблемы. Дело в том, что разработчиков  - особенно высоклассных - очень сложно заставить писать документацию. Это крайне медленный процесс, в течение которого разработчикам приходят в голову новые мысли и они начинают их реализовывать, что не только замедляет работу над документированием, но и вызывает частый прогон тестов, что также отнимает время. На этом этапе нас покинул второй программист, сказав, что он понимает важность создания документации, но он все-таки программист, а не технический писатель. К счастью, основной объем ПО к этому моменту уже был реализован. Именно тогда я понял, почему в проект должны работать не только высоклассные специалисты, но и начинающие  - они могут взять на себя ту работу, которая профессионалам уже наскучила и кажется неинтересной.

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

В конце проекта архитектор ушел, и думаю, в этом есть большая часть моей вины. Дело обстояло так: я, как руководитель отдела, был плотно загружен как другими проектами, так и пресейловой активностью, и не мог уделять проекту все свое время. А в конце проекта организационные задачи, как известно, сильно возрастают как в объеме, так и в процентном отношении. Я все-таки пытался сделать так, чтобы он взял на себя общение с продакт-менеджером и вообще перерос в полноценного менеджера проекта. Вот только продакт-менеджер нам достался, как бы сказать помягче, не совсем качественный. У меня-то были привитые на соответствующих тренингах навыки общения с людьми, которые не могут сказать пары предложений, не оскорбив собеседника, но для архитектора это было тяжелым испытанием. Он решил, что состояние психического здоровья для него важнее завершенного проекта, и перешел в другую компанию.

Потерять архитектора в конце проекта - это очень тяжело. С учетом того, что на этот проект было завязано еще несколько, и маркетологи объявили повсюду, что контроллер готов. Пришлось спешно заниматься закрытием проекта самому, за счет остальных работ, и привлечь в проект еще несколько людей. Проблем с предъявлением контроллера заказчику не возникло - полученное им на предыдущем этапе устройство практически не изменилось, он уже вовсю с ним работал у себя. Большинство работ было связано со сдачей документации (мы закрывали проект на этапе разработки РКД), половина из которой никому, кроме военной приемки, была не нужна.

 

Итоги проекта

Получившееся устройство имело такой внешний вид:

Avia_pcb

 

Контроллер функционировал в полном соответствии с ТЗ, закачик был очень доволен. Описание рекламной листовки - здесь. Пресс-релизы о контроллере появились как на нашем сайте, так и в других изданиях - CNews, Avia.ru, и даже Connect. На базе контроллера было затем разработано семейство изделий авионики, на него была портирована ОС реального времени QNX.

 

Награды

Контроллер отмечен дипломом победителя конкурса «Продукт года 2008 Control Engineering Россия» в номинации «Встраиваемые системы», а также специальным дипломом как наиболее интересная и перспективная отечественная разработка, представленная на конкурсе журнала "Современные технологии автоматизации" («СТА») в номинации «Лучший проект АСУ ТП».

 

Уроки, извлеченные мной из этого проекта:

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

2. Если человека тянет в архитектурное проектирование, то пытаться насильно сделать его менеджером проекта - верный путь его потерять

3. Команду проекта возможно целиком подобрать с улицы, но нужно очень точно формулировать требования к людям в заявке HR на специалистов.

4. Если проект требует работать, большей частью, по новой, не прошедшей массовую обкатку технологиии, необходимо закладывать риски не менее 50%.

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

6. Дополнительные человеческие ресурсы для проекта всегда можно найти, надо уметь искать.

7. Лучший способ оставаться в графике - искать и выкидывать ненужные работы.

8. В графике проекта с госзаказчиками необходимо предусматривать значительные время и деньги на сдачу  проекта, по крайней мере - 15%.