Регулярно всвоей практике и практике коллег встречаю доказательства тому утверждению, что большее сокращение затрат на процессы (в том числе и разработки) можно решить организационными изменениями.
«Нужный человек не в том месте может перевернуть мир» ©G‑Man/Half‑life
Никакие технические решения не дадут того же эффекта. В принципе, чаще они даже не срабатывают, так как нет привычки работать «правильно» у самих сотрудников. Все попытки автоматизировать хаос приводят только к интенсификации этого хаоса.
В этой статье я расскажу на одном личном примере, как посредством организационных изменений можно значительно сократить временные затраты на процесс (в моем примере — это процесс разработки), одновременно с этим повысить качество продукта этого процесса.
Исходное состояние
Меня пригласили в компанию на место руководителя отдела разработки оборудования. Отдел на тот момент уже имел восьмилетнюю историю и штат из шести человек.
Запрос от руководства был довольно простой в формулировке и, на самом деле по ситуации в отрасли, распространённый:
продукты не нравится пользователям
нет нужных модификаций продуктов
разработчики что-то все время правят, но ничего не меняется
часы списывают, но непонятно что на выходе
разработчики отказываются применять новые решения так как “это сложно”
почему продукт стал именно такой - никто ответить не может
Проведя аудит процесса разработки, команды и самого продукта, выявил определенные отклонения от «академического».
В общем случае процесс разработки имеет в качестве основного входа запрос на разработку, основным ресурсом выступают кадры (собственно разработчики), управляющим воздействием являются установленные в компании принципы разработки, а на выходе имеем продукт. При этом продукт состоит из двух неразрывных компонентов: товар/услуга и документация к ним.
О мерах настройки каждого входа и выхода можно посвятить отдельные увесистые статьи. Я же постараюсь рассказать о них кратко и по порядку.
Запрос на разработку
В компании за 8 лет сложилась практика передачи запроса на разработку с помощью любого доступного канала общения:
Написать в корпоративной почте
Запросить на совещании
Написать в мессенджере (их в компании было 3)
Попросить лично
Все эти каналы могли быть адресованы:
Лично разработчику
Руководителю разработчика
Сотруднику смежного подразделения
Руководителю смежного подразделения
Через продакт-менеджера
Что кратно увеличивало общее количество источников входящей информации для отдела разработки.
Формулировка таких обращений всегда имела вид “хочу так…” и никогда не содержала пояснения вида “зачем?” или “какую проблемы хотим решить”.
Каким бы способом не были получены эти обращения, они оставались строго в ведении конечного получателя - одного разработчика, но всегда разного, кому “посчастливилось”, зачастую оставляя остальных участников процесса в неведении, полном или частичном.
Принципы разработки
При распределении заданий на разработку не обращали особое внимание на уровень компетенции избранного разработчика и на основную сферу его компетенции, его профессиональный фокус.
«Ты‑ж разработчик — разрабатывай».
В ежедневном отчете столбец «Название проекта» фигурирует не с проста. Каждое задание на создание модификации продукта воспринималось как новый проект. И тут возможны были два варианта:
несмотря на наличие полного аналога в портфеле, делается разработка «с нуля», заново повторяя большинство ошибок прошлых разработок — создается «тупиковая ветвь» в продуктовой линейке;
берется в качестве основания существующий аналог из линейки продуктов, тот, который был указан в тз от заказчика, без анализа применимости этого аналога, а потом наворачивается сверху множество новых и уникальных решений, без намека на возможность их последующего использования.
Правил расстановки приоритетов не было, потому каждый разработчик оценивал приоритет для задач и выстраивал порядок этих задач на свое усмотрение.
Интервал планирования был 1 месяц — достаточный, чтобы потерять внимание и контроль над задачами.
Управление кадрами
Коллектив разработчиков состоял из людей совершенно разных возрастных категорий. Каждый со своим набором приоритетов в работе, чаще противоречащим с коллегами.
Но все были едины в одном: поверхностные знания о требованиях к продукту со стороны регулирующих организаций и со стороны непосредственных пользователей и нежелание их изучать. «Что заказчик в ТЗ написал, то и делаем» — основная заповедь в работе.
Со стороны заказчика поступает ультимативное требование по срокам выполнения задач, за нарушение которых строго наказывали. Но и однозначности не было. Задержать с выполнением задачи на 5% — это плохо? А на 10%? Также не сообщалось, что будет, если исполнитель справится раньше.
Все каждый день исправно заполняли отчет о проделанной работе. В котором были два столбца: «Название проекта» и «Часы». Каждый в обязательном порядке присутствовал на всех совещаниях. А их немалое количество набиралось: встречи отделом, встречи с производством, встречи с заказчиками (а их было 7, по одному для каждой линейки продуктов).
При этом эфирного времени на разработчика приходилось не более 10ти минут из 1 часа, отведенного на совещание. Но в совокупности с низким уровнем Soft skills, этого времени было достаточно, чтобы любое обсуждение перешло в деструктивное русло.
Как результат выгорание и безынициативность.
Продукт
В итоге за 8 лет получаем продукт, состоящий из большого количества линеек оборудования, которые не связаны между собой по применяемым решениям. Нет согласия и внутри самих линеек. Каждый отдельный экземпляр одновременно содержал в себе “родовые травмы” выбранного аналога и уникальные решения.
Документация на продукт представлял собой “Мурзилки”, как их часто называли сами сотрудники, которые могли только помочь вспомнить ранее ознакомленному с ними сотруднику, как все работает. Но для нового ознакомления она была бесполезна, потому старались за пояснениями обращаться к первоисточнику - разработчикам.
Что было сделано
Существовавшую команду разработки организационным решением разделили на 2 части, по 3 человек в каждой. Таким образом мы остались втроем, а вторая команда занялась технологическим сопровождением производства.
Поставленные задачи нужно было как-то решать имеющимися ресурсами.
Скажу сразу, что никаких принципиально новых решений в ходе предпринятых корректировок создано не было. А как показала моя дальнейшая практика - для оптимизации и выстраивания процессов не нужно ничего изобретать, все уже разработано до нас. Нужно только правильно применить лучшие практики.
В основу всех моих решений легли следующие труды:
«Теория решения изобретательских задач» от Генриха Альтшуллера
«Теория ограничений» от Элияху Голдратта
«Дао Toyota» от Джеффри Лайкера
его спин‑офф, Lean startup от Эрика Риса
«Спроси маму» от Роберта Фицпатрика
«Getting Things Done (GTD)» от Дэвида Аллена
Запрос на разработку
В случае отсутствия в системе (информационной или технической) необходимой функции подход ТРИЗ, при некотором упрощении, дает следующее решение (первый постулат) - создай эту функцию. При этом необходимо использовать строго то, что уже есть в системе. Вот это важно, не нужно создавать новый элемент в системе, нужно именно создать функцию, используя имеющиеся элементы.
В нашем случае, так как я не мог повлиять на количество источников информации, то проще было создать функцию сбора запросов на разработку в общий “котел”. Чтобы разработчики уже использовали его как единый информационный канал. Для это достаточно было использовать уже имеющийся в компании редактор табличных документов.
Для каждой модификации и версии продукта создали файл, в котором делали запись по шаблону:
Дата
Автор
Суть замечания
Комментарии / ссылка на доп. материалы
Данные из этих таблиц агрегируем в запросы на линейку в целом, а потом со всех линеек - на продукт в целом.
Собранные в этот котел обращения из состояния “хочу так…” нужно было преобразовать к виду аналогичному при формулировании гипотез - “если мы (сделаем так то), то получим (вот это) за счет (того то). Обращу внимание, что важно уметь формулировать не только позитивные гипотезы, но и негативные.
Так как существовавшие каналы получения информации только вводили в заблуждение сильными искажениями, то тут нужно было прибегнуть ко второму постулату, исходящему из учения Альтшуллера. Если в системе мешает какой‑то элемент, то его нужно убрать, сохранив важные функции. Потому перешли к прямому сбору информации по указанным проблемам. Это же решение диктует Дао Toyota — пойди и узнай лично.
В своей практике я выделил 3 основных и эффективных метода исследования:
Погружение — используй продукт, как пользователь. Это позволит свежим взглядом обратить внимание на моменты, о которых привыкший пользователь может и не вспомнить
Наблюдение — смотри, как с продуктом работают другие. Найди все вредные и полезные привычки, которые опытные пользователи выработали.
Интервью — не фантазируй, а спроси. Важно проводить его не в распространенном варианте изнуряющего сорокаминутного допроса, по Фицпатрику. То есть получить ответ на один главный вопрос за 10–15 минут, не задавая его «в лоб», а серией сторонних открытых вопросов.
Важно стараться применять их именно в таком порядке и не пропуская ни один.
Принципы разработки
Один месяц — это долго, Lean startup советует сократить период разработки до минимальной возможного. Поэтому декомпозируем задачи, чтобы постепенно, каждый раз закрепляя привычку сотрудников работать в меньшем диапазоне времени, перейти к спринтам. Вначале 2-х недельным, затем к недельными. В итоге приходим к набору декомпозированных задач со сроком на выполнение меньше недели, а недельный спринт заменяем на недельный релизный цикл.
Дао Toyota говорит следующее: думай долго, действуй незамедлительно. Потому в работе в первую очередь нужно планировать последовательность действий команды. Мы имеем «котел», хоть и разобранных и уточненных обращений, но работать с ним еще нельзя. Разобраться с ним поможет GTD Дэвида Аллена. Из всей массы выделим обращения, свидетельствующие о реальных ошибка (багах), которые нарушают функциональность продукта. И нужно отработать в первую очередь с максимальным приоритетом. Считаем, что пользователь зажег «красную лампочку» (по принципу Дао Toyota: сделай остановку производства с целью решения проблем частью производственной культуры, если того требует качество).
Следующим шагом из оставшегося массива обращений нужно выделить те, доработать которые получиться очень быстро. В качестве критерия взял срок, составляющий 10% от релизного цикла, то есть 10% от 40 часов — 4 часа. Можем сделать быстрее 4х часов — помечаем как «быстрая задача».
К оставшемуся списку применяем удобную и привычную систему расстановки приоритетов разработки. Мы выбрали MoSCoW.
Управление кадрами
Первый аспект управления кадрами, который нужно было исправить — это эффективное использование рабочего времени.
Оба разработчика и имели ярко выраженную I‑компетенцию. А для участия в совещаниях со смежными подразделения и с заказчиками нужна уверенная T‑форма компетенции. Имеем противоречие в системе: чтобы разработчику своевременно получать информацию, он должен присутствовать на самих встречах, но не может ввиду недостаточных навыков коммуникации. Теория ограничений Голдратта в таком случае утверждает, что было принято неверное решение на предшествующем этапе. Получать актуальную информацию не обязательно с совещаний и встреч — система обращений вполне выполняет необходимую функцию. А разработчик должен заниматься в первую очередь разработкой. Потому разработчики и были исключены со встреч, и было запрещено получение задач в личном порядке — все через систему обращений.
Так как при детальном рассмотрении зоны интересов заказчика установлено, что его интересует в первую очередь результат работ в желаемый срок, а не количество потраченных на это часов, то сотрудников освободили от заполнения ежедневных отчётов.
Второй аспект — корректная оценка трудозатрат на полученную задачу.
Исполнитель будет стараться указывать плановое время с большим запасом, создавая буфер задачи, это подтверждается работами Голдратта. Решением является по договоренности между заказчиком и разработчиком явное указание размера этого буфера.
Размер буфера определяется как разница между максимальный сроком завершения (то есть указанным исполнителем) и наиболее вероятным сроком завершения. При наличии данных об оптимистичном, пессимистичном и наиболее вероятном сроках завершения однотипных задач в прошлом, ожидаемый срок завершения можно найти по следующим формулам
Зачастую исторических данных нет, и оценка от исполнителя, само собой, не устроит заказчика. Разрешить возникший конфликт в системе, когда желание по срокам от заказчика учитывать нужно, но оно будет с большой долей вероятности не выполнимо, поможет 3й постулат, исходящий из ТРИЗ Альтшуллера. Если не можешь исключить из системы элемент, то используй его функцию по другому. В данном случае оценку по сроку от заказчика мы воспринимаем как экспертное мнение о минимальном сроке завершения задачи, а оценку от исполнителя - как максимальную оценку. Тогда ожидаемое время завершения можно определить по следующей упрощенной эмпирической формуле.
На графике видно, что в таком случае появились 5 зон для оценки сроков выполнения:
Справился быстрее экспертной (минимальной) оценки - Синяя зона
Справился в промежутке от экспертной до наиболее вероятной
Справился в промежутке от наиболее вероятной до собственной (максимальной) оценки
Превысил собственную оценку, но не более чем на 1 сигма
Превысил собственную оценку более чем на 1 сигма
Такой 5ти цветный светофор по задачам учитывает два мнения, менее зависим от степени их субъективности, и (самое главное) дает ответ на вопрос исполнителя “а что если…”. Обязательный контроль со стороны руководителя в середине согласованного срока, а потом дополнительный контроль в середине оставшегося срока. Таким образом реализуется принцип сигналов по Дао Toyota, чтобы проблему отловить еще на “желтом сигнале” и решить ее, не допустив возникновения критической проблемы - “красного сигнала”.
Третий аспект управления кадрами - это их индивидуальное развитие. Для этого совместно с самим сотрудником создаем карту всех его компетенций. Каждый зафиксированный навык оцениваем по 3х бальной шкале:
Владение на базовом уровне только в типовых ситуациях
Уверенное владение в нетиповых, незнакомых ситуациях
Владение на высоком уровне с возможностью успешно научить ему другого сотрудника
Все навыки делим на soft и hard, обязательно помечаем навыки как применимые и неприменимые для текущей роли.
По этим картам выявляем области возможного роста, и сотрудник самостоятельно выбирает навык, который он будет развивать и выбирает соответствующие обучающие курсы.
Продукт
Обновили классификацию всей номенклатуры производимых товаров в соответствии сегментами пользователей, особенностями применения и изготовления. Итого было выделено 4 линейки продуктов. Большое количество товарных групп, которые изначально рассматривались как полноценные линейки были определены как принадлежности к основным линейкам, чтобы впоследствии производить согласованные изменения.
Каждая линейка строилась по принципу модульной конструкции вокруг одного базового варианта. Расширение функций производилось за счет добавления модулей. Весь контроль за гармоничной увязкой отдельных модулей между собой и с базой в процессе их развития и модернизации сводился в контроле за коннектором (участками соединения и подключений).
Результат
На осуществление всех описанных изменений потребовалась 4 года. В результате удалось выстроить непрерывный поток информации от идеи до ее воплощения.
Запрос на разработку
Постоянный контакт с непосредственными пользователями позволяет не только держать руку на пульсе актуальных тенденций и пожеланий пользователей, но и приводит к выстраиванию паритетных, а иногда и товарищеских, отношений с пользователями. Таким образом постепенно происходит “обрастание” первыми последователями. В соответствии с рекомендациями Lean startup.
Принципы разработки
В начале каждого релизного цикла (напомню, был выбран интервал 1 неделя) происходит оценка новых отработанных обращений и переоценка старых обращений. В разработку в первую очередь берутся задачи с отметкой “ошибка”. Далее если, есть время, то берутся задачи с приоритетами “must”, “should” или “could”. Если после заполнения планового рабочего времени на неделе остается еще время на “быструю” задачу, то разработчик самостоятельно выбирать наиболее интересную. Решение “быстрой задачи” позволяет разработчику получать дофамин с меньшими затратами сил, тем самым сохранять баланс между выполнением задач и получением удовлетворения от проделанной работы. Возможен также случай, когда разработчик сталкивается с временным “затыком” (творческий кризис) в одной крупной задаче. Тогда, при условии отсутствия по ней “пожара”, он паркует задачу и на релизный цикл полностью переключается на “быстрые задачи” - отдыхает с пользой. Обратно к приоритетной задаче возвращается уже морально отдохнувший, а иногда с новой идеей, подчерпнутой в быстрых задачах.
Управление кадрами
Освобожденные от регулярных и неэффективных повинностей сотрудники перестают ощущать стресс от неопределённости в запланированной работе.
Привитая практика промежуточного контроля позволяет сотруднику самостоятельно проводить критическую оценку процесса разработки и участвовать в митигации рисков по задачам.
Прозрачная зависимость получаемой мотивации от сроков выполнения и от приобретенных навыков даёт ощущение непосредственного участия не только в процессе разработки, но и в развитии отдела и продукта в целом.
Продукт
По истечении 4х лет 3 линейки продуктов были полностью модернизированы, в 4й линейке модернизировано 2/3 вариантов исполнений. Также выпущена вторая улучшенная версия базовой модели для одной линейки продуктов, приступили к созданию второй версии для еще одной линейки.
В документации организовано сквозное отображение входящего обращения и его влияние на различные решения о модернизации.
Послесловие
Я выбрал именно этот пример из личного опыта, потому что, как показала моя предыдущая и последующая практика, описанные проблемы в той или иной степени характерны для большинства процессов разработки, вне зависимости от сферы их применения (разработка hard или soft). Использованные при этом методы решения во многом дополняют и даже повторяют друг друга, потому к одному и тому же решению можно прийти опираясь на разные методики — главное выбрать для себя ту, которая вам больше симпатизирует.