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

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

 

Старт

У любого руководителя существуют 4 типа коммуникации - с руководством, коллегами, заказчиками и подчиненными. Собственно, 90% своего рабочего времени руководитель (который является действительно руководителем, а не техлидом) тратит на коммуникацию, и этого времени постоянно не хватает. Удлиненный рабочий день здесь не является выходом, так как, во-первых, не все те люди, с которыми я имею дело, готовы оставаться на работе допоздна, а во-вторых, надо общаться и со своей семьей. Вопрос - где взять резервы? Стандартный ответ - делегирование.

 

Общение с заказчиком

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

 

Общение с подчиненными

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

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

 

Общение с коллегами и руководством

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

 

Решение текущих организационных вопросов

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

Делегирование для текучки я организовал так - если ко мне приходили с какой-то просьбой, я создавал в трекере JIRA запрос, в котором формулировал эту просьбу, и возвращался дальше к своей деятельности. За день таких запросов могло набираться до 20. Будучи хорошо знакомым со свойством технарей забывать про все, если попадется интересная задача, координатора я подбирал как раз по полному отсутствию скиллов в программировании и электронике - впрочем, если выбирать среди девушек, это не такая уж трудная задача. Все, что требовалось - психологическое образование и умение общаться с компьютером на приличном уровне.

С утра следующего дня координатор включала компьютер и начинала просматривать список неразрешенных запросов. Чтобы я мог больше заниматься действительно управлением, а не разгребанием мелких завалов, я делегировал координатору максимум полномочий, которые было можно. В итоге мне приходилось реагировать не более, чем на 5 запросов в день, а это означало, что на текучку я тратил в 4-5 раз меньше времени. Хотя, конечно, никто за меня не просматривал ТЗ перед подписанием и не разбирал вопросы о повышении зарплаты.

 

Организация взаимодействия между подразделениями

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

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

 

structure_task2

 

Оптимизация процессов

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

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

 

Делегирование пресейловой активности

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

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

risklist

 Разумеется, все это техлиды знали и так, но вот вспомнить это при составлении графика удается далеко не всегда.

 

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

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

uml

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

 

Документирование

Следующим вопросом было документирование. Учитывая тот факт, что наш Институт работал, большей частью, с госзаказчиками, доля трудоемкости по созданию документации в проектах достигала 30% (в некоторых - до 70). Многим руководителям известно, что нет лучшего способа заставить разработчика написать заявление об уходе, чем посадить его на месяц за документирование. Учитывая, что моя задача была прямо противоположной, я постарался снять с разработчиков возможно большую часть работ по документации, взяв на работу техписателей. Поиск был долгим (проблема с их дефицитом известная, кто искал - знает), но в конце концов я нашел людей. Одним из новшеств было начало документирования не в конце проекта, а в середине - когда уже имется достаточная информация и остается время для маневра, если вдруг свалится срочная работа.

 

Отчетность

В Институте существует система планирования и учета рабочего времени с помощью MS Project Server.

Процесс происходит так: вначале техлиды, переговорив с исполнителями, формируют в MS Project диаграмму Гантта и согласовывают ее с руководителями проектов. Как всегда, возникают споры о сроках и бюджете, но это решается. Или не решается - тогда от проекта отказываются, если нет иных причин для выполнения проекта, кроме получения прибыли.

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

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

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