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

Бизнес-идея заключалась в следующем: ранее, в процессе работ по удаленному мониторингу мы научились делать очень компактные и функциональные устройства, собирающие информацию и передающие ее по радиоканалу. Несколько проектов такого рода было нами сделано и передано заказчикам. Но в связи с широким распространением SensorID прибыльность в этом секторе снизилась – чтобы продать что-то в этой области, необходимо было выпускать устройства миллионами штук, а это требовало больших вложений без какой-либо гарантии их окупаемости - конкуренция на рынке очень большая. Поэтому стали искать другую нишу – в которой деньги делаются на использовании интеллектуальной собственности, а не простоте и дешевизне продуктов. Это позволяло выходить на рынок постепенно, без больших начальных вложений в материальные запасы.

В процессе поиска наше внимание привлекла реклама кардиоимпланта фирмы Transonic. Поразила цена – 10000$ за один имплант, не считая всего остального, которое тоже стоило очень недешево. Удивили и довольно-таки скромные характеристики прибора – была твердая уверенность, что сможем сделать лучше. Написали бизнес-план, директор его одобрил – и стартап начался. Как было записано в ТЗ, "комплекс предназначен для беспроводного мониторинга биофизических параметров подопытных лабораторных животных в процессе медицинских экспериментов и предоставления данных мониторинга географически удаленному пользователю в реальном масштабе времени по протоколу TCP/IP." 

 

Описание системы

Система в развернутом состоянии имеет следующий вид:

rat_architecture_2

 

Небольшие пояснения: импланты, размером 25х20х8 мм вшиваются в подопытное животное (обычно крысу) и передают данные о ее физиологических параметрах по радиоканалу в трансивер. Трансивер принимает информацию от импланта и передает ее на сервер. Сервер служит для авторизации пользователей и передачи данных. Рабочие станции соединяются с серверами и отображают в клиентской программе, написанной на Java, данные мониторинга в реальном времени.

Было написано несколько статьей по этой теме - их можно посмотреть здесь и здесь. Можно также посмотреть рекламный постер для выставок.

 

Начальный этап разработки

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

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

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

 

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

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

Продакт-менеджер

Программист (встраиваемое ПО)

Программист (прикладное ПО) - из другого подразделения Института

Инженер-электронщик, также писал тестовое ПО

Монтажник

Инженер-механик - оутсорсер, г.Владимир

Хирург - оутсорсер, из МГУ

 

Механическая часть системы (имплант)

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

Первая версия импланта, которая была вшита в крысу, выглядела следующим образом:

 

implant_case

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

Позднее мы расширили число каналов импланта до четырех, и упаковка компонентов стала совсем плотной:

 

Тестирование

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

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

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

Ситуацию прояснил знакомый выпускник физфака, с которым мы болтали о пустяках и попросили его взглянуть на устройство. Он взглянул, и поинтересовался, знаем ли мы, что такое капиллярный эффект. И тут все стало понятно. Провода, которые снимали кардиограмму, были очень тонкими (0,5мм), с пластиковой изоляцией. Жидкость, находящаяся внутри крысы, проходила по проводам, как по капиллярам, внутрь корпуса импланта и заливала плату. Проблема была решена в течение часа - место присоединения проводов к плате изолировали клеем, и этого оказалось достаточно.

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

Особенно запомнился еще один баг. Как-то наш программист чувствовал себя неважно  и писал дома, удаленно выкладывая исходники под версионный контроль. После одного обновления код работать перестал, пошли сбои. Программист же утверждал, что все тесты у него дома проходят без сбоев, и присылал логи. Собрали консилиум и стали разбираться, в чем дело, пока один человек не обратил внимание на разный размер исполняемых модулей нашего и программиста - различие было на 3 байта. Попросили программиста прислать исполняемый файл и прогнали тесты с ним - все заработало нормально. Поскольку makefiles тоже лежали под версионным контролем, версия о разных вариантах сборки была отметена с ходу. Отключили оптимизацию и стали смотреть соответствие С-кода и объектного файла - оказалось, что операция 16-битного битового сдвига реализована некорректно, 13-й бит инвертируется - на нашей версии gcc. Программист же использовал последнюю версию, где этот внезапно возникший баг  компилятора был уже устранен. 

 

Управление продуктом

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

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

 

Прикладное и встроенное ПО

Сложность программной части все больше возрастала. В начале проекта мы расценивали соотношение трудоемкости разработки программной и аппаратной части как 1:5, в конце проекта оказалось, что получилось почти наоборот, 3:1. Пришлось вводить версионный контроль с ветками, каждая ветка была предназначена для испытаний того или иного варианта ПО. Главной проблемой была энергопотребление - мы постоянно находились между необходимостью убрать избыточное кодирование данных для снижения потребления энергии радиопередатчиком и нестабильностью радиоканала, для устранения чего, собственно, и применялось избыточное кодирование. Подобрать оптимальное решение оказалось возможным только прогоном множества вариантов ПО из разных веток  и анализов лог-файлов. Некоторые куски кода в критических секциях переписывались на ассемблере, чтобы ускорить работу и тем самым сократить потребление энергии.

Достаточно интересно получилось с написанием клиентской программы для просмотра данных. Сделать ее было решено на Java ради кроссплатформенности, написали SRS и отдали на разработку подразделению, программисты которого был не загружены на тот момент. Относительно быстро получили первую версию программы, проверили ее - прогнали тесты, поправили ошибки и успокоились.

 

javaclient2

 

Как выяснилось, зря - Java требует серьезных аппаратных ресурсов компьютера, на компьютерах разработчиков и моем, достаточно мощных машинах, она работала отлично, но перерисовка экрана на нескольких одновременно работающих клиентах с использованием Swing отнимала почти все аппаратные ресурсы у более слабых машин, на Celeron 1ГГц работать было вообще нельзя - даже перерисовка тормозилась. Естественно, мы вернули продукт на доработку, но программисты оказались заняты на другом срочном проекте и окна не предвиделось еще несколько месяцев. Тогда мы, благо была завершенная и реализованная в процессе разработки SRS, собственными силами переписали клиента на LabWindows (аналог Visual Studio для отображения результатов измерений). Кроссплатформенностью пришлось пожертвовать на данном этапе, но взамен получили быстро работающий вариант, нетребовательный к аппаратной части РС.

 

4channelscreen

 

Проектное управление

В одно прекрасное утро я понял, что, немотря на работу по 10-12 часов в день, постоянно не успеваю сделать все, что запланировал. Я сел за стол, попросил никого меня не трогать и выписал на ежедневнике все задачи за этот день. Среди них были такие как «проверить реализацию кода, касающегося обмена с чипом радиопередатчика», «Поправить в SRS п.3.6.28 для альтернативного сценария». Всего оказалось около 15 задач (это сейчас я понимаю, что выписал далеко не все, а тогда мне это показалось запредельной цифрой). Каждый раз, выполняя или откладывая ту или иную задачу, я вычеркивал ее название или переписывал ее на следующий день. Вначале было трудно, но я привык. Потом, когда через пару недель я просмотрел записи, обнаружилась довольно интересная закономерность: в те дни, когда я не брался за инженерные задачи, все организационные были выполнены. В те же дни, когда я брался за инженерные задачи, не были выполнены ни они, ни половина организационных задач. После долгих раздумий я понял, что надо сделать выбор –  или я контролирую все лично и успеваю сделать только половину, либо активно заниматься делегированием задач. Так, например, я беседовал с человеком и спрашивал, какие работы он намерен выполнить и за какое время. Потом вместе с ним составлял график и согласовывал его с графиками других людей, с которыми беседовал таким же образом. Заодно заметил интересную вещь – оказывается, человек, лишенный постоянного контроля, работает быстрее и качественнее. Сейчас-то я понимаю, что инженеры, во-первых, лучше работают без давления, а во-вторых, просто хотели оправдать доверие, но тогда мне это казалось очень странным. Так, естественным образом, я перешел от контроля процесса к контролю результата.

Фактически, мы работали по принципам Agile, очень близко к Scrum - разумеется, не осознавая этого факта. Конечно, прямого аналога,например, Sprint Backlog мы не вели. Мы перешли к принципам Agile эволюционным образом, поскольку требования менялись очень часто, и единственным способом выжить - было как-то подстроиться под постоянную смену требований. Конечно, сейчас жалею, что тогда не читал книжки по теории проектного управления - можно было бы вместо изобретения велосипеда сконцентрироваться на других вещах.

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

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

Продакт-менеджер был у нас очень активным. Он постоянно общался с заказчиками, приносил все новые и новые требования, и это постоянно выбивало нас из графика. Например, в процессе разработки мы сделали очень сильную с технической точки зрения вещь - четырехканальный имплант, но он не нашел своей доли на рынке. В конце концов, я ввел в проекте то, что называется «управление конфигурацией» - сделал единый канал внесения изменений и потребовал письменно оформлять запросы на все изменения, приступая к ним только после одобрения их вышестоящим руководством и завершению очередного блока работ.  Пришлось разделить требования по степени важности ( это не был Scrum-овский Product Backlog - мы тогда про Agile ничего не знали). Конечно, пошли протесты но я твердо стоял на своем  - либо мы получим продукт, который можно будет продавать, либо будем иметь кучу незавершенки в процессе и не получим вообще ничего в финансовом смысле. Мое непосредственное руководство меня поддержало, и работа вновь вошла в прежнее русло.

 

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

Проект шел, результаты все больше и больше приближались к намеченным показателям, и в один прекрасный день мы объявили, что цели проекта достигнуты. Импланты работали в соответствии с ТЗ, наши коллеги из МГУ выступали на конференциях с докладами по ним, демонстрируя результаты и презентации такими картинками:

 

Rat_complex

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

Устройство показывали на многих выставках, например, Russia Hi-tech в Малайзии. К нам в Институт приезжал Дмитрий Медведев, тогда еще бывший одним из премьеров, он тоже видел комплекс в работе. 

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