Управление разработкой в «горизонтальных» компаниях: расшифровка онлайн-встречи. Часть 1

30  октября мы провели встречу с СТО и техническими руководителями Райффайзенбанка, Mindbox и ЦИАН, где за два часа постарались максимально охватить непривычную для российского рынка IT-компаний тему управления разработкой без менеджеров. В ходе разговора выяснилось, что «плоскость» («горизонтальность») у каждой из приглашенных компаний — своя. Под катом — видео со встречи и расшифровка первой ее части.

Митап был длинный и насыщенный, поэтому мы разделили его на два поста: первый, вы читаете его сейчас, — это ответы гостей на вопросы, которые выбрали в нашем сообществе в Фейсбуке; вторая — ответы на вопросы «из зала» от слушателей — выйдет на следующей неделе.

Гости

• Сергей Кононенко, CTO в Райффайзенбанке

• Никита Прудников, CTO в Mindbox

• Михаил Юматов, руководитель разработки в Циан

• Ведущий: Алексей Рыбак, CTO «Везёт».

Темы первой части

Для встречи мы подготовили 14 больших тем и попросили сообщество проголосовать за те, которые более всего интересны. В итоге выбрали эти:

• Функциональные иерархии в «плоских» компаниях: есть ли они? Чем в таких компаниях занимаются СТО?

• Коллективная или персональная ответственность? 

• Обратная связь в командах

• NoEstimates или жесткие сроки?

Если вы больше любите смотреть, чем читать, то полное видео встречи можно посмотреть здесь:

Если вы хотите послушать вводную часть о компаниях, в которых работают гости, то смотрите видео до 0:41:40. Дальше начинается обсуждение того, как работают в «горизонтальных» компаниях: в Райффайзенбанке, Mindbox и ЦИАН. Ведущий — Алексей Рыбак, СТО «Везет».

Ниже –– расшифровка дискуссии.

Чем занимаются СТО, тимлиды и техлиды в «плоских» компаниях. Как устроено техническое управление разработкой?

Алексей Рыбак: Вопрос: чем занимаются CTO? Вторая часть этого вопроса: Сергей, давайте начнем с тебя.

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

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

Когда один CTO, и при этом открывается много-много направлений, его же разорвет? Все-таки какая-то структура под них есть? Какая-то команда, которая помогает в том числе разговаривать с бизнесом?

Сергей Кононенко: Мои техлиды — это и есть моя команда. В команде есть leadership team, у каждой команды есть product owner, техлид и, если команда работает по Скраму, то скрам-мастер. И три этих сотрудника являются leadership-командой.

Алексей Рыбак: То есть это какая-то роль, на которую ты промоутируешь внутри этой команды, ты на нее назначаешь?

Сергей Кононенко: Я нанимаю людей на техлидов. Это может быть найм снаружи или найм изнутри. Но чтобы сразу предупредить следующий вопрос: техлид не является административным руководителем сотрудников в команде.

Алексей Рыбак: Да, понятно. Спасибо большое. Тогда, Никита, ты расскажи, как у вас?

Никита Прудников: Чем занимается CTO? Я формулирую, во-первых, интерфейсы команд. В том смысле, что есть команда, она в какой-то степени автономна. Мне надо понять, в какой степени команда внутри себя принимает решения, в какой степени мне важно шарить горизонтальную экспертизу между командами, может ли команда взять и решить двигаться к своей платформе — такие вещи. 

Плюс — интерфейсы. В смысле, что команда дает наружу. То есть я формулирую то, как работает надежность в компании. И прямо сейчас я работаю плотно с бизнесом и формулирую очень четкий, автоматизированный SLA компании, при этом он каскадируется внутри команды. То есть у каждого продукта есть свой SLA. 

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

Алексей Рыбак: Один? У тебя есть какая-то еще команда, которая тебе помогает? Сергей сказал, что в каждой команде есть техлид. И так или иначе с группой техлидов можно решать какие-то задачи уже непродуктового характера. Я так понимаю, что у тебя похожая история или нет?

Никита Прудников: Я не назвал бы это прямо команда, это просто какой-то круг. Да, роли закрепленные есть. В принципе, очень похоже на то, что в «Райффайзене». У нас в команде есть техлидер, человек, который в первую очередь отвечает за надежность, во вторую — работает вместе с PO [product owner], я бы даже сказал, со стейкхолдером этого продукта. В качестве технического эксперта он понимает, как строит роадмэп этого продукта дальше: насколько рискованно вставлять какие-то вещи, сколько это займет разработки. Помогает, в общем, как-то, очень грубо.

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

Алексей Рыбак: Давай еще раз, это кто? Это один чувак, который отвечает за процесс, за то, что команда функциональна? Второй чувак, который отвечает за вопросы надежности? И продакт, который отвечает за выручку?

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

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

Алексей Рыбак: Понял. Никита, спасибо. Михаил, как у тебя?

Михаил Юматов: Как мы уже выяснили, у меня не все так плоско. Есть лиды направлений, и у них могут быть еще и лиды команд. Соответственно, все эти ребята подо мной. Если говорить про мою задачу, то это общая цель и стратегии развития продуктовой части IT относительно целей бизнеса, какие-то личные цели, направление с точки зрения IT-целей бизнеса. Найма, рост, помощь ребятам в той или иной степени по движению по этим целям.

Алексей Рыбак: У вас есть кто-то в команде? Почти половину своей карьеры я провел в компании Badoo. Мы росли, были сначала очень маленькие, гаражный стартап. С первого дня я там работал почти до самой продажи,   12 лет. У нас был такой условный… Мы не были плоскими в том понимании, в котором мы сейчас говорим. Но были достаточно гибкими и очень демократичными тем не менее. У нас был институт тимлидов, техлидов как некая отдельная группа, которая вместе жила, собиралась. У них были свои какие-то цели. У вас есть что-то подобное?

Михаил Юматов: Да. Если говорить про гильдии, точно такая же, как гильдия питонистов, есть гильдия тимлидов. Мы все вместе собираемся, вместе же обсуждаем какие-то IT-цели, проблемы и так далее, куда нужно двигаться, развиваться, что менять. Но сейчас даже здесь немножко размывается. Раньше по IT-стратегии мы двигались составом тимлидов. Сейчас привлекаем в том числе и разработку, делаем прозрачней все, что происходит. Предлагаем всем, кому угодно, вовлекаться и участвовать в развитии в составе рабочих групп, помимо своих команд. Принимать участие в достижении целей.

Алексей Рыбак: Михаил, здесь тогда еще небольшой вопрос. Все предыдущие ребята сказали, что тимлиды у них (или техлиды) не являются руководителями. А ваши тимлиды — это тимлиды, которые являются руководителями программистов, инженеров?  

Михаил Юматов: Да.

Коллективная или персональная ответственность. Обратная связь. Вознаграждения

Алексей Рыбак: Давайте перейдем к следующему тоже очень животрепещущему вопросу. Он очень краткий. Коллективная или персональная ответственность? 

Но давайте я все-таки разверну. Если мы откатимся к истоку, к фреймворку Scrum, то мы вспомним, что в Скарме одним из принципов и одним из actors является команда. И в идеологии Scrum личность и команда находятся в определенном зависимом положении. В первую очередь любой успех — успех команды независимо от того, что происходит. 

Это является частью идеологии. Огромное количество людей со мной спорят по поводу того, что Scrum — это идеологические фреймворки, продолжая утверждать, что там очень много именно идеологии, пришедшей много откуда. Но очень часто возникают вопросы, типа: кто виноват. Да никто не виноват, команда виновата. Если очень упростить.

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

Если схлопнуть, это будет все-таки командная ответственность или персональная ответственность? Сергей, давай начнем с тебя. Ты что про это думаешь? Как у вас?

Сергей Кононенко: «Райффайзенбанк» — банк немаленький. И все очень зависит от зрелости команды. Если команда зрелая, то, конечно, командная ответственность в первую очередь. Ребята сами внутри у себя разберутся, как так получилось, что что-то пошло не так. Если команда незрелая и она еще не пришла к состоянию, когда может сама разобраться в себе, то приходится подключаться.

И тут может появиться и какая-то история, когда где-то в переговорке один на один с человеком переговорят и объясняет ему, что где-то он сделал что-то не очень и так больше делать не надо.

Алексей Рыбак: Скажи, пожалуйста, я правильно понимаю, что фактически ты утверждаешь, что через какое-то время, это, по-видимому, работа скрам-мастеров, все команды должны дойти до точки, когда команде разговор о персональной ответственности просто не нужен? Для вас это некий таргет?

Сергей Кононенко: Да, это можно сказать.

Алексей Рыбак: То есть можно сказать, что для вас таргет — это командная ответственность?

Сергей Кононенко: Да.

Алексей Рыбак: Тогда еще небольшой вопрос. Скажи, а какие-то вознаграждения персональные у вас есть? Или они тоже командные?

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

Алексей Рыбак: Понял. Хорошо. Никита, как у вас: персональная или коллективная ответственность?

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

Отрицательная обратная связь у нас есть с помощью один на один. И часто мы с разрешения человека через какое-то время ее [отрицательную обратную связь] в каком-то формате делаем доступной. Не то что она публикуется на канале «Доска позора», но при этом, если человек будет направлено искать, он ее найдет.

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

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

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

Алексей Рыбак: Какой-то конкретный человек подвел. Важный проект, часть на себя взял, была какая-то оценка. А я так понимаю, что оценка у вас есть. В любом случае произошло какое-то ожидание о том, что эта часть будет выполнена тогда-то. И она не была выполнена.

Никита Прудников: Подожди, сейчас хочу переложить это наш процесс, чтобы лучше сформулировать ответ. Этот человек, в смысле, разработчик?

Алексей Рыбак: Да, инженер.

Никита Прудников: Инженер в рамках именно командной роли функционирует в Kanban. Он не может ошибиться очень сильно.

Алексей Рыбак: Как это так? Может же.

Никита Прудников: Он не берет на себя месячные задачи, это все-таки задачи, которые…

Алексей Рыбак: Недельную же берет?

Никита Прудников:   Недельную он берет.

Алексей Рыбак: Взял недельную задачу и вдруг не сделал. 

Никита Прудников: Понятно, но это в рамках автономии разрулится, я даже не вмешиваюсь в такое. То есть не смог — там дальше какая-то рефлексия происходит. В смысле: «Чувак, что за дела?» Это уже внутри команды, не я туда вмешиваюсь.

Алексей Рыбак: Но при этом кто является инициатором этого обсуждения?

Никита Прудников: Зависит от того, на чьи цели это влияет. Если человек сильно набаговал и произошел отказ в продакшене, то, скорее всего, инициатором будет техлид, потому что это его цели. Если систематически такое происходит и начинают плыть цели команды долгосрочные по роадмэпу, то, скорее, стейкхолдер. Когда есть персональная ответственность и конкретные цели у людей и они в принципе бегут про одно, то не обязательно иметь формальную роль человеку, который дает обратную связь, оно просто происходит. Они между собой поговорят и такие: «Что-то не так», — и поговорят с этим человеком, и все.

Алексей Рыбак: То есть поговорили один раз и, допустим, поговорили еще раз, потому что это повторилось. И дальше может быть несколько сценариев. Есть сценарий, когда по-другому реорганизуются задачи, есть сценарий, когда появляется краткосрочный ментор, появляются какие-то краткосрочные цели, improvement plans с определенными целями. Как у вас? Или просто сразу — хоп, хоп.

Никита Прудников: Слушай, все это может происходить. Обычно мы стараемся процесс с целями тоже делать прозрачным. Мы все процессы на Trello cторим. У нас есть доска, называется «Обратная связь и ЗП». И она несколько функций выполняет. Например, когда человек хочет повысить зарплату, он заводит прямо на этой доске карточку: «Я, Петров/Иванов. Хочу 200 000». И мы в рамках процесса выработали шаблон. Он пишет — почему хочу, в смысле, какие цели я выполнил, какие цели я себе ставил, при этом хорошо бы указывать ссылку на прошлую свою карточку, какие там цели. И магия случается в последней колонке, потому что там сидит бухгалтерия. И если никто не ветирует эту карточку, пока она доедет, там уже зарплата повышается.

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

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

Алексей Рыбак: У нас, вроде, нет ни в Mindbox, ни в  остальных компаниях европейских подразделений. Это очень сильно от культуры зависит, то, о чем я сейчас скажу. Но эта актуализация плохого и исправление плохого — это штука, которую тоже надо вырастить. И это штука, которая не идет изначально. Она может протухнуть сама собой. То есть люди будут под ковер заметать мусор, и один-два раза не будет никакой реакции, потом то же самое оказалось где-то еще. И как с разбитыми окнами. У вас с самого начала было так?

Никита Прудников: Именно культуру прозрачности мы строим последние лет шесть. Где-то, наверное, в 2014 или 2015 году у нас открылись зарплаты полностью внутри. Компания тогда была маленькая.

Алексей Рыбак: Кому-то что-то не нравится, и люди открыто начинают это обсуждать, в том числе не нравится чей-то перфоманс. Понимаешь, ты сказал очень умную вещь. Ты сказал о том, что если c перфомансом что-то не так, то происходит какой-то разговор. Этот разговор происходит сначала непублично, потом появляется публичная карточка. Я правильно понимаю?

Никита Прудников: Ну да.

Алексей Рыбак: Правильно понимаю, что все члены команды другие видят о том, что появилась какая-то история?

Никита Прудников: Да, конечно.

Алексей Рыбак: Не было ли у вас такого, что это какие-то обиды порождало?

Никита Прудников: Я бы сказал так: эта культура — это такие правила игры внутри компании. И у нас бывает, что люди не принимают эти правила. Например, во время испытательного проекта. То есть довольно сложный онбординг. 

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

Алексей Рыбак: Хорошо. Михаил, как у вас обсуждаются, в том числе такого рода коррекционные действия, коррекционные планы. «Коррекционные» — плохое слово. Но по-русски «планы улучшения» тоже не звучит.

Михаил Юматов: Если кто-то что-то накосячил со сроками или чем-то, то в любом случае это обсуждается на ретроспективе всей команды. Но при этом и лид этой команды персонально уже работает на регулярных встречах, one-to-one [1:1] с этим человеком, если это требуется. Если это какая-то систематическая история или требуется какой-то рост ответственности или еще чего.

Алексей Рыбак: Классно, что ты вспомнил, вылетело у меня совершенно из головы. А быстрый кроссчек? Никита, а у вас есть one-to-one?

Никита Прудников: Да, в каком-то смысле.

Алексей Рыбак: У тебя все инженеры, говоришь, по штатке репортят тебе. У тебя со всеми есть one-to-one?

Никита Прудников: Тебе снова надо уточнить термин, что ты подразумеваешь под «one-to-one»? «Один на один» обратная связь – да, у нас есть.

Алексей Рыбак: «Один на один» обратная связь и возможность создать для сотрудника такие условия, когда он регулярно делится самым сокровенным?

Никита Прудников: Да, конечно, причем в разных ролях. Например, человеку нужно помочь сформулировать цели…

Алексей Рыбак: Ты же не сможешь со всеми провести, если их 60? Более конкретно: с кем у программиста one-to-one и как часто?

Никита Прудников: У программиста one-to-one чаще всего с его техлидом либо стейкхолдером, либо HR. В зависимости от того, как он захочет.

Алексей Рыбак: Окей, хорошо. Как часто?

Никита Прудников: Обычно раз в полгода они карточки заводят на повышение зарплаты.

Алексей Рыбак: Раз в полгода? Понятно, хорошо.

Никита Прудников: Кто-то тянет. Бывает, раз в год. На этот счет потом, если интересно, я вам могут рассказать и минусы всего этого подхода. Просто сейчас очень конкретного ответа ты ждешь.

Алексей Рыбак: Такой подход, при котором one-to-one не очень-то и нужны. Других у меня объяснений one-to-one раз в полгода нет. One-to-one раз полгода в другой компании — это просто бесполезный one-to-one. Он очень редкий.

Никита Прудников: Возможно.

Алексей Рыбак: One-to-one — две недели максимум, обычно неделя. И, если это не процесс… Там ретеншн у людей совершенно другой будет. Хорошо.

Сергей, быстрый вопрос к вам. One-to-one есть?

Сергей Кононенко: Есть, примерно раз в две недели с техлидами. Если нужно, могут скрам-мастера позвать или продакт оунера.

Алексей Рыбак: Людей, которые не являются их руководителями?

Сергей Кононенко: Да.

Алексей Рыбак: У меня тогда еще такой вопрос. А почему бы просто не назначить их руководителями? Это какая-то большая сложность? Оставить все то же самое, просто сделать их руководителями?

Сергей Кононенко: Тогда у техлида появится формальная власть административная. Мы этого не хотим.

Алексей Рыбак: Вы этого не хотите почему? Он ей будет пользоваться как-то во вред?

Сергей Кононенко: Да, мы не хотим, чтобы техлид принимал волюнтаристские решение. Мы хотим, чтобы он убеждал опытом, знаниями, какой-то харизмой, а не: «Я начальник, я так сказал. А если не послушаешься, я тебе зарплату срежу».

Алексей Рыбак: Ладно, понятно.

Михаил, сорри. Я сделал этот быстрый кроссчек, спасибо тебе большое, что ты напомнил про one-to-one. Это тоже интересная часть процесса, она по-разному характеризует компании. Но еще, ко всему прочему, ты все так сказал, по крайне мере, мне кажется, это все достаточно понятно. Понятная структура, понятное решение проблем. Она, с одной стороны, демократичная, стримы продуктовые развернуты, с другой стороны, иерархична. Классическая, я бы даже сказал, продуктовая матрица, если угодно. Правда, сейчас заклеймили это слово, и у многих оно автоматом вызывает, какую-то коннотацию отрицательную.

Давайте на этом пока закончим. Я хотел поговорить про NoEstimates еще.

NoEstimates, жесткие сроки или «всё сложно»?

Алексей Рыбак: Давайте попробуем кратко затронуть «NoEstimates». Три варианта ответа: NoEstimates, жесткие сроки и «все сложно», как в Facebook. И, если «все сложно», потом расскажете, но пока блиц.

Никита, как у вас: NoEstimates, жесткие сроки или «все сложно»?

Никита Прудников: Все сложно, конечно.

Алексей Рыбак: Отлично. Сергей, у вас?

Сергей Кононенко: Все сложно.

Алексей Рыбак: Михаил, как у вас?

Михаил Юматов: У нас тоже все сложно.

Алексей Рыбак: Я думал, что ты скажешь: «Жесткие сроки».

Михаил Юматов: Нет.

Алексей Рыбак: Тогда с тебя начнем. Почему «все сложно»?

Михаил Юматов: Жесткие сроки — зачем, с какой целью? Действительно бывают ситуации, когда жесткие сроки нужны, когда действительно нужно вывести на рынок какое-то изменение прямо к конкретной дате. Но чаще всего — какая-то более гибкая история, когда туда-сюда чуть-чуть можно подвинуть за счет чего-то. 

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

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

С этой точки зрения, оценки важны, но жесткие сроки, кажется, что тоже должны быть оправданы.

Алексей Рыбак: На предварительном обсуждении ты говорил, что у вас есть все-таки такой процесс, вы стараетесь обучать команды, принуждать команды к оценке. Когда я говорю про NoEstimates, на самом деле, многие тоже по-разному понимают этот подход, но многие говорят о том, что оценки вообще вредны и оценивать не надо: «Как сделаем, так сделаем. Мы же взрослые люди». Много есть объяснений. Но в основном это разговор о том, что и оценивать-то особо смысла нет.

Все-таки у вас, я так понимаю, оценка происходит.

Михаил Юматов: Происходит.

Алексей Рыбак: Как приучить команду давать более реалистичные эстимейты, если не просить их давать регулярно?

Михаил Юматов: Мы просим. Я не знаю ответа на этот вопрос. Условно, взять разработчика. Если он не задумывается о том, за сколько он что-то сделает и не соотнесет это с фактическим каким-то результатом, то, наверное, у него не будет данных для какой ретроспективы и выводов по самому же себе. Не сможет развиваться в этом направлении, давать более точную оценку, понимать, где он что-то упустил, где-то что-то не учел.

Алексей Рыбак: То есть все-таки какая-то оценка происходит, и на ретро или на каких-то отдельных процессах идет разговор типа: «Почему так? Почему ошиблись? Что надо сделать для того, чтобы улучшить?» То есть такой процесс есть?

Михаил Юматов: Все верно.

Алексей Рыбак: Но при этом не каждая задача получает какую-то оценку в срок? Или все-таки каждая? Я сейчас поясню…

Михаил Юматов: Каждая.

Алексей Рыбак: Каждая?! Но ты говоришь — «все сложно», а на самом деле жесткие сроки у тебя.

Михаил Юматов: Видимо, я неправильно понял, что ты имеешь в виду под жесткими сроками. Жесткие сроки — это не уложился в задачу, тебя дрючат?

Алексей Рыбак: Нет-нет-нет. Хорошо, сорян. Жесткие сроки — это когда каждая задача или почти каждая задача для того, чтобы пойти в разработку, выйти из стадии обсуждения, получает определенный срок. Я не говорю, что жестко происходит реакция на случай, если со сроками что-то произошло не так. Всякое, может быть. Но, по крайней мере, такое есть принуждение к тому, чтобы сроки были. И дальше ретро: почему не совпало, если не совпало сильно.

Никита, как у вас?

Никита Прудников: Давай сформулирую. Просто у нас Progressive JPEG, как у многих. То есть большие — долго и не точно, а есть маленькие и быстрые — здесь. И все, что пулится в команду — почему я говорю про NoEstimates с нюансами — оно не оценивается. Но ключевой вопрос, который задает себе команда в тот момент, когда она пулит в себя историю: успеет ли она сделать этот инкремент за неделю, с учетом параллелизма внутри команды, загрузки, всего такого. 

Если это можно назвать оценкой, то, наверное, это оценка. Хотя, наверное, не совсем корректно называть это оценкой, потому что они не оценивают, за сколько сделают эту задачу. Они проверяют, смогут ли они успеть ее за недельный размер блока работы. И Kanban у нас работает с такими недельными блоками.

Бывает, что команда видит, что это совсем просто, меньше дня делается. Тогда они еще быстрее это пропихивают. И в этом смысле я говорю, что у нас внутри команд NoEstimates. При этом есть более крупные каденции. Например, у нас вся разработка, при том, что внутри команд Kanban, работает месячными каденциями. При этом не совсем правильно называть это скрам-спринтами, потому что между ними нет промежутка. То есть это какие-то отметки просто.

На эти каденции команда для себя ставит какие-то цели на основе работы архитектора. И в этот момент тоже какая-то оценка этих целей происходит. То есть сколько этих недельных блоков он займет.

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

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

Алексей Рыбак: Ты используешь аббревиатуру DoD. Это definition of done? 

Никита Прудников: Да, definition of done.

Алексей Рыбак: Хорошо, тогда быстро еще. Задача попадает в трекер с оценкой по сроку или нет?

Никита Прудников: Ей не нужна оценка, потому что мы считаем, что задачи в трекере — меньше недели.

Алексей Рыбак: Понял. Хорошо. Перейдем сейчас к Сергею. Сергей, если можно, кратко. Как у вас: задача оценивается, не оценивается? В чем ваша сложность?

Сергей Кононенко: У всех команд — по-разному. Более зрелые, менее зрелые по-разному работают. Кто-то оценивает в днях, кто-то оценивает в сторипоинтах, а кто-то не оценивает совсем.

Алексей Рыбак: То есть сложность просто, потому что много людей?

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

На следующей неделе выпустим вторую часть встречи в текстовом формате. Там гости будут отвечать на вопросы «из зала», которые в прямом эфире задавали слушатели. 

У нашего сообщества есть Фейсбук-группа «Управление и разработка крупных IT-проектов» и канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техноблогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.