1. Завод и IT-компания

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

Нас весьма удивляет тот факт, что в системе массового производства рабочие завода практически не нуждались в общении. Считалось правильным, если они работали, не разгибаясь, как каторжные.

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

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

Тем не менее до сих пор многие производители оборудования по-прежнему выпускают станки, охающие и грохающие на всю Ивановскую. Бережливое оборудование — это тихое оборудование.

Бережливое производство. Дэниел Джонс, Джеймс Вумек

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

“Отдел проектирования” (менеджеры) спускают на завод (разработчиков) задания на производство (таски в джире). Рабочие (программисты) клепают детали (фигачат код) и отгружают заказы (релизят фичи) не задумываясь о результате. Процесс идёт, все при деле.

2. Человек-станок

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

Зачем разработчикам общаться с кем-то? Это трата рабочего времени!

Знакомое рассуждение?

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

Зачем ему видеть дальше следующей таски? Не его ума дело.

Вся работа разделена по отделам. Выстроена иерархия. Есть разработчики, есть менеджмент, отдел тестирования. Задачи спускаются сверху вниз.

Разработчику не нужно знать зачем ставится задача — его дело “работать руками”, набрать код. “Работают головой” те кто поставил задачу: проектные менеджеры, продакт-менеджеры.

Плохо ли это? Ведь это успешно работает на практике.

3. Лишнее общение

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

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

За этим следует полный отказ от общения. Из крайности “слишком много общения” мы падаем в другую крайность “никакого общения”.

Как можно отказаться от лишнего общения и сохранить возможность общаться?

Предлагаю вооружиться следующими принципами.

  1. Никакой обязаловки. Посещение любой запланированной встречи должно быть добровольным. Отказаться можно без всяких негативных последствий.

  2. Исключить встречи ценность которых не очевидна.

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

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

Исключаем лишнее общение, оставляем то общение, которое приносит ценность.

4. Улучшения без общения

…Для решения производственных проблем и улучшения процесса рабочим обязательно надо общаться друг с другом.

Разберём это утверждение. Представим, может ли улучшаться процесс, если работник полностью изолирован от общения.

Может ли изолированный от остальных работник улучшить свою эффективность?

Скорее всего может.

Станет меньше отвлекаться, научится быстрее писать код, будет реже ошибаться. Это ускорит выполнение задачи на этапе порученном этому сотруднику, причём только если задача выполняется именно этим сотрудником.

Как отдельная производственная ячейка, он повысит эффективность. Но в масштабах компании это будет незаметно. Ведь всё остальное осталось прежним.

Может ли изолированный от остальных сотрудник улучшить эффективность других коллег в своём отделе?

Наверное нет.

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

Каким образом он узнает что другим это нужно? Никто ему об этом не скажет. Он не знает, кто чем занят. Не может сказать “эй, погоди, ты оптимизируешь запросы, давай я помогу с этим, у меня большой опыт”.

Каким образом он сможет передать знание? Другие сотрудники изолированы и не желают тратить время на “болтовню”.

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

Обмен знаниями в отделе отсутствует.

Может ли изолированный от остальных сотрудник улучшить работу других отделов?

Тоже нет.

Общение с отделом выше, ниже или вообще не стоящим рядом по иерархии не приветствуется. Даже общение с тем кто спустил ему задачу для уточнения условий может быть воспринято негативно, как “трата времени на разговоры вместо дела”. Не говоря уже об остальных отделах.

Он никогда не узнает, что и как делается в других отделах. Никто с ним этим не поделится сам, а если он займётся расспросами то встретит непонимание.

Получается, что системные улучшения без общения невозможны, возможны только локальные. Нельзя улучшить процессы без общения.

5. Команда

Команда — группа людей, сплочённых ради единой цели.

Можно ли считать командой кучку людей, которые полностью изолированы друг от друга?

Вряд ли.

Это сборище “винтиков” практически ничем не отличается от группы нанятых фрилансеров.

Ничего не зная друг о друге и о работе друг друга, они не усиливают других, не помогают. Не развивают друг друга.

Каждый сам по себе.

6. Ломаем стены

Нет ничего более бесполезного, чем эффективное выполнение совершенно неважной работы.

Питер Друкер

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

Улучшения внутри отдела

Общение позволяет команде быть командой, в которой эффективность каждого усиливается благодаря остальным.

У команды есть компетенции, каждый член команды силён в чём-то.

  • Допустим я могу помочь коллеге с проблемами оптимизации под хайлоад, в том числе оптимизации SQL запросов. Или со сложным рефакторингом.

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

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

  • Четвёртый проектировал некоторую фичу в продукте и может помочь тому кто её дорабатывает.

Общение позволяет делиться знаниями и быстрее решать проблемы.

Улучшения процессов

Общение даёт знание о происходящем вокруг. Знание о происходящем вокруг делает процессы прозрачными для всех.

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

Традиционно роль улучшения процессов лежит на менеджменте. На уровне своих подчинённых за процессами приглядывает тимлид, выше уровнем руководитель отдела, ещё выше менеджеры разных уровней.

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

Примеры узких мест в процессах, которые могут быть выявлены:

  • Разработчики увидели, что тестировщики тратят много времени на ручное тестирование апи. Возникает идея автоматизировать тесты и высвободить время тестировщиков, тем самым сократить этап тестирования.

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

  • Выяснилось, что на ревью тратится много времени на правки стиля кода. Возникает предложение полностью автоматизировать этот шаг утилитами, чтобы не тратить на это время на ревью. Задача идёт в релиз быстрее.

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

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

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

7. Выводы

Вывод который я сделал для себя:

Хорошая коммуникация это ключ к постоянному улучшению работы.

Вам же предлагаю всё обдумать и сделать выводы самостоятельно. Надеюсь, что эта статья была полезной для вас.