Так сложилось, что практически во всех компаниях, где я работал (а это были и маленькие фирмы, и стартапы, и даже корпорации), часто практиковали какие-то подходы к управлению разработкой, но по факту ситуация выглядела так.
Разработчикам закидывают много разных задач и даже проектов “в параллель”. Часто довольно плохо понятно, ЧТО и КАК надо сделать. Ты долго разбираешься: и хорошо ещё, если есть какая-то актуальная документация и не надо пытаться понять, то ли в доке ошибка, то ли ты тупой. А еще мир не идеален и регулярно что-то где-то ломается, а разработчиков, которые писали тот код, давно уже нету. Давать какие-то оценки сроков в таком формате практически нереально, а начальство уже нарисовало дедлайны и запуски, — и ходит недовольное.
Бизнес в свою очередь часто не понимает, что происходит по задачам, и старые таски теряют актуальность. Так что он приносит новые, которые, конечно, нужны прямо здесь и сейчас. Ничего личного, просто ИТ-отдел очень дорогой и бизнес пытается добиться максимальной окупаемости расходов на разработку. Как умеет.
При этом, интересный факт, - обе стороны обычно понимают, что для комфортной работы нужны нормальные процессы, рефакторинг, уменьшение техдолга. И даже всеми руками за это! Но продолжают копить баги, взаимное недовольство, за которым следуют увольнения — и снижение желания работать у тех, кто остается.
Как разработчику мне всегда жилось довольно некомфортно в таких условиях и хотелось сделать так, чтобы можно было спокойно работать. Поэтому я шел общаться с коллегами и с бизнесом, и если мы признавали, что есть проблема с текущими процессами, я пробовал что-то менять. Формальный ок от всех получен, и дальше начинается самое интересное.
“Хочешь быть скрам-мастером? Да пожалуйста!” (подождите кидать помидоры)
Обычно мы договаривались попробовать решить проблемы через скрам. Что такое аджайл, не знает никто, канбан часто понимали на уровне “доска со стикерами и что-то про Тойоту”. А вот про скрам все слышали больше (каждый первый уже специалист, хех). Так что проще всего предложить сделать скрам-команду. Сказать, что те же дейлики зададут ритм, дадут понимание текущего статуса и актуальных проблем, которые у нас есть.
Важно! Здесь и далее я буду говорить о личной интерпретации скрама:
Для меня скрам - это в первую очередь про команду. Про то, как можно быстро из группы людей сделать классную команду, которая достигает совместных целей. Это про эффект синергии, когда 1 + 1 становится > 2. Я очень здорово прочувствовал этот эффект, когда играл с коллегами в баскетбол. Круто чувствовать что-то такое и в работе.
Конечно, это подходит не всем. Был в моей практике случай, когда человек честно сказал, что он не хочет синков в команде. А хочет четко поставленных задач от менеджера и готов в письменном виде сделать отчет о работе за день. И решил покинуть компанию. Но за всю свою практику я помню только один такой кейс. Большинство ребят как минимум не против работать в команде, а некоторым даже нравится эта идея.
Командообразование без корпоративов и веревочных тренингов
Те же дейлики дают хорошую основу для командообразования, потому что мы начинаем больше знакомиться и общаться. Но прежде чем запускать их, я делал небольшую встречу, где мы обсуждали, у кого какие личные цели, кто чего хочет, какая могла бы быть командная цель. Раз мы строим команду, хорошо иметь общую цель, которая будет всем актуальна и будет объединять людей: одна из команд, где я проводил такую штуку, быстро стала самой эффективной в компании, а ребята дружат и много лет спустя.
А следом у нас появляется совместная активность — дейлик, который служит и достижению нашей цели (обсуждаем проблемы и ищем решения), и помогает дальше знакомиться: небольшие “светские беседы”, пока все подтянутся, никто не отменял.
Я сам классический программист-интроверт и не особый любитель общаться. Такие короткие встречи помогали мне постепенно познакомиться с коллегами, и стало проще задавать вопросы, почему в коде решили сделать так заковыристо, а не корпеть над проблемой в одиночку. Задачи стали решаться проще и быстрее. Я часто наблюдал такой эффект в своих командах. Если ребята знают хотя бы, кого как зовут, кто чем занимается, то гораздо проще и быстрее начинается общение и вопросы решаются гораздо быстрее.
Теперь, когда люди понимают, зачем им стендапы
Так или иначе, все задачи, которые я получал как разработчик, всегда были частью большой картины. Например, мне надо сделать REST API. Случалось, что мы обсудили API c фронтом, а в следующем спринте приходит мобильная команда и говорит, что ее API не устраивает, давайте переделывайте. А фронты во время реализации задачи наткнулись, что есть похожий на нужный им готовый компонент, но дизайнеры решили рисовать с нуля. Пока мы жили отдельной жизнью, своими спринтами, в своих кабинетах, задачи сильно растягивались и было много взаимных недовольств.
Совместные встречи на 15 минут позволили нам синхронизироваться сразу. Буквально за пару минут прямо на дейли удавалось договориться, какой компонент использовать и как можно было немного изменить дизайн, чтобы значительно ускорить разработку. Мобильные разработчики давали фидбек на API в тот же день, и их интересы сразу можно было учесть. Вместо игры в “горячую картошку” перекидывания задач в джире теперь мы решали проблемы либо сразу же дейлике, либо отдельно - но тоже находили решение.
С помощью дейликов мы не только понимали, кто что делает, и решали проблемы, но и
вспоминали, какая у нас общая цель и как каждый вносит вклад в нее.
Но есть и другая точка зрения
Конечно, я не всегда встречал полное принятие новых практик сразу. Часто попытки внедрить дейлики, ретро и это все воспринимаются как новая менеджерская причуда. И в ответ прилетает куча возражений:
Для меня скрам - это в первую очередь про команду. Про то, как можно быстро из группы людей сделать классную команду, которая достигает совместных целей. Это про эффект синергии, когда 1 + 1 становится > 2. Я очень здорово прочувствовал этот эффект, когда играл с коллегами в баскетбол. Круто чувствовать что-то такое и в работе.
у нас и так много собраний, не хочу еще одно, дайте поработать,
я быстрее в чате статус напишу,
у нас все распределены по миру и/или свободный график, не найдем общий слот,
уже пробовали раньше, по несколько часов, пустая трата времени,
на дейлике под 15+ человек будет, час там просидим,
вы еще сразу подробные отчеты с почасовкой тогда требуйте и тайм-трекер введите,
и, как говорится, you name it.
Если перефразировать, останутся два основных возражения: “Это бесполезно для меня как разработчика и отнимет время” и “Я не хочу жесткого контроля”. В обоих случаях меня выручал рассказ про команду, смещение фокуса на общие задачи и “давайте просто попробуем неделю так пожить”. Обычно ребята соглашались на пилотный запуск, а дальше уже моей задачей было сделать так, чтобы дейлики проходили быстро, без “а почему так мало было сделано вчера” и реально помогали людям решать их вопросы и получать признание за работу (когда впахиваешь как Папа Карло, это же, черт возьми, приятно).
Я тоже не хочу ходить на встречи, которые считаю для себя бесполезными. Тоже не люблю формальности ради формальностей. Тоже не хочу сидеть на синках часами и заполнять таблички. И я такой же участник команды, как и все остальные.
Поэтому мы сделаем встречу на 15 минут, не больше: найти такой слот можно, даже если сильно в разных часовых поясах. Соберу состав так, чтобы там было немного людей и только нужные: в идеале не больше 7 человек, чтобы информация у участников успешно влезала в "оперативную" память (см. кошелек Миллера). Мы будем обсуждать, что осталось сделать и что нужно, чтобы успешно достичь наших целей. Актуализировать задачи можно в джире. А вот услышать, что опять упал тестинг и QA по 30-60 минут тупо ждет, пока все пересоберется, эскалировать наверх и решить вопрос — как говорится, бесценно.
Такие 15-минутные дейлики довольно легко начать проводить. Конечно, это всего лишь начало большого пути, но на моем опыте уже в первые недели они давали классный результат, помогая нам становиться командой.
