Алексей Пименов — Ну что? Когда доделаете задачу?

Друзья, рад приветствовать вас в нашем зале.

Пожалуйста, поудобнее устраивайтесь те, кто находится в зале.

Поближе подвигайтесь к мониторам те, кто у нас находится онлайн.

Не забывайте готовить ваши вопросы спикеру.

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

И начнет сегодня наш день.

доклад, посвященный прогнозированию и оценке задач.

Его нам представят консультант и преподаватель современных методов менеджмента Алексей Пименов.

Привет!

Алексей, пока мы не начали, небольшой вопрос.

Скажи, пожалуйста, ты наверняка сталкивался с таким термином, как «чайка менеджмент».

Конечно.

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

Вообще, в принципе, стоит ожидать.

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

Нет.

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

А еще, кстати, в менеджменте есть целый орнитарий, и я их коллекционирую.

Помимо чайка-менеджеров есть кукушка-менеджеры.

Это менеджеры, которые прилетают и подкладывают вам работу, причем часто свою работу.

Потом появился в нашем орнитарии сорока-менеджмент.

Как ведет себя сорока?

Сорока хватает все, что блестит, тащит к себе.

То есть обладает высокой насмотренностью, не знает ни одну технологию глубоко.

Управленческую, я имею в виду.

И максимум, что можно сделать, кидаться рандомно в вас статейками.

И последняя находка для орнитарии – это птичка, которая называется приоритетерев, которая постоянно к вам прилетает и требует, что вот эта вещь должна быть в приоритете.

Если у вас еще есть какие-то птички, вы мне как-нибудь пишите, я буду коллекционировать их.

Спасибо, Алексей, за орнитарий.

Удачи на докладе.

Спасибо.

Пожалуйста.

Итак, давайте начнем.

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

Может голова начать болеть и тому подобное.

Но давайте все-таки начнем, потихоньку будем погружаться.

Итак, меня все еще зовут Алексей, я все еще консультант по менеджменту.

И мы сегодня с вами будем говорить о такой наболевшей для всех теме, которая называется «Оценка».

Оценивать не любят, оценивать не умеют.

И это стоит всегда признавать.

То есть менеджеры просят у своих инженеров оценки.

Инженеры приходили работать не для того, чтобы давать оценки.

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

Почему оценивать сложно?

Потому что оценка, во-первых, включает очень много неопределенностей.

То есть мы с вами сотрудники умственного труда.

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

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

И, в принципе, прогноз изготовления всегда получать неплохо.

У вас любая задача, которая на вас прилетает, она уникальная.

Такой никогда не было и больше не будет.

Потому что если она будет не уникальная, то это решается очень просто.

Ctrl-C, Ctrl-V. Сами прекрасно знаете.

И вот в этих условиях нам нужно отвечать на вопросы.

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

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

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

ты в пользу оценок и необходимости оценок начинаешь высказывать, встречают эмоциональный отклик.

Эмоциональный отклик, который обоснован тем, что накопилось на работе.

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

И менеджеры сейчас я не имею в виду линейный или проектный руководитель.

Я имею в виду скорее продуктовые менеджеры.

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

И таких целей две.

Первая цель.

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

Ну то есть любому продакт-менеджеру ваша оценка...

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

Понятие оценки и понятие прогноза завершения.

Вот здесь как раз идет оценка.

Или прогноза длительности завершения, так скажем.

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

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

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

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

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

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

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

Вы себе заказываете какой-то новый гаджет.

Например, для компа или что-то такое себе домой.

И у вас есть два выбора.

Вы можете заказать его на Wildberries и Ozone, а можете заказать на AliExpress.

На AliExpress, возможно, будет дешевле, но доставка будет дольше.

На Wildberries и Ozone это может быть дороже, но доставка будет быстрая, потому что со складов каких-то местных не надо везти из Китая.

И опять же, понимание вот этой сроков доставки для вас будет являться решающим при выборе откуда,

делать заказ необходимого инструмента.

Это первый фактор.

Второй фактор.

Знание прогноза длительности реализации важно для планирования следующих действий.

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

Вот здесь я нарисовал такой пример.

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

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

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

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

И давайте теперь поставим точку.

То есть вот есть две причины, по которым у вас просят оценки.

Эти причины легитимны, эти причины нормальны.

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

Это уже другая история.

Но, по крайней мере, как из коробки, продакт-менеджер просит у вас оценку по вот этим двум причинам.

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

И первая вещь.

Суммирование оценок задач не дает оценки целой фичи.

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

То есть разбив крупную какую-то фичу на таски, оценив каждую таску в человеко-часах и сложив эти человеко-часы, вы не получите длительность реализации.

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

Вы знаете, что такой сетевой график, скорее всего, называется диаграмма Ганта.

И получить все-таки какой-то прогноз.

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

и оценкой реализации целого проекта или фичи.

Вот эта штука более-менее понятна для тех, кто вообще связывался с этим.

Но теперь я скажу ещё менее понятную вещь.

Длительность реализации не связана с трудозатратами вообще.

Как вам такое?

То есть вы говорите какие-то вещи, а они не складываются вообще никак.

Итак.

Давайте немножечко погрузимся в историю, то есть почему это такая штука.

Вообще длительность реализации и трудозатраты на индивидуальные какие-то задачи,

Это связывание длительности реализации с индивидуальной оценкой элементарных задач.

Она вся идет где-то из 40-х, 30-х годов прошлого столетия.

И вот как раз возникновение такого инструмента, как диаграмма Ганта, связано было со строительством чуть ли не Empire State Building.

И так как этим диаграммам Ганта уже скоро стукнет 100 лет, и от этого инструмента еще не отказались, значит, где-то он показал свою эффективность.

Ну так почему же в IT-отрасли у нас не любят диаграммы Ганта?

Да, всё дело в том, что показатели того, от чего зависит время реализации, в IT-отрасли они чуть-чуть другие.

То есть мы не делаем индивидуальное какое-то здание, сосредоточившись на нем.

У нас есть фабрика, фабрика приложений, фабрика фичей, фабрика требований в рамках проекта, в которой задействовано большое количество людей.

У них есть производственный процесс.

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

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

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

Много разных вещей.

Потом есть зависимости.

Зависимости на другие команды, зависимости на готовность каких-то вещей, зависимости на инфраструктуру.

Постоянные изменения приоритетов.

Наверняка вы слышали страшные такие слова, что мы живем в каком-нибудь вукомире, в котором все меняется, рынок меняется очень быстро.

Наверняка еще слышали такое слово, как agile.

Все очень-очень быстро меняется, и надо с этим что-то делать.

То есть приоритеты постоянно меняются, мы что-то бросаем ради того, чтобы что-то новое начинать.

И влёты.

То, что вообще никто не любит.

Это когда вот этот приоритетерев прибегает, говорит, вот это новая задача, и, соответственно, давайте вот она будет в приоритете.

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

Его зовут Даниэль Ваканти.

Он выпустил две замечательных книжки.

Одна называется «Actionable Agile Metrics for Predictability», вторая называется «When Will It Be Done».

Достаточно прочитать только первой.

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

Книга Actionable Agile Metrics, она вышла не так давно, это что-то типа 2016 год.

Но вообще саму по себе природу оценок в IT более глубоко стали изучать где-то году в 2005-2006.

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

Он в 2003 году выпустил книжку про оценку гибких проектов.

И эта книжка, только-только она опубликовалась, как она сразу стала неактуальной.

Почему?

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

Например, такое допущение, которое называется «аддитивность оценок».

Представьте себе такую вещь.

Вы используете у себя, например, относительные оценки.

Кто знаком с термином story point?

Наверняка все практически знакомы.

О, ну вот.

Так вот, смотрите, у вас есть одна фича, она стоит один story point.

Есть другая фича, она стоит один story point.

Допустим, вы их делаете последовательно.

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

Потом вы берете фичу, которая занимает два story point, и это не значит, что ее делает месяц.

Вот так.

А Майкон делал допущение, что вот оно так работать будет.

Практика доказала, что оно так не работает.

И...

Я сталкивался с исследованиями в разных частях мира.

То есть, по-моему, зовут такого человека Лео Маширони.

Он делал исследования в США, делал большую выборку проектов и оценок этих проектов айтишных.

И пытался найти математическую корреляцию между сроком реализации проекта.

Ну, под проектом можно понимать какую-нибудь просто крупную фичу.

Или эпик, как вы можете там назвать их.

И оценкой.

И не нашел никакой математической корреляции.

Я знаком с таким человеком, которого зовут Андреас Бартелл.

Это немец.

И он работал в крупной компании немецкой, которая занимается разработкой всяческих...

инструментов для лотерей, Lotto24, по-моему, что ли, называлась эта компания.

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

И вот этот вот товарищ Даниэль Ваканти тоже не находил таких корреляций.

И тогда задаёмся вопросом, да, вообще от чего тогда это всё зависит?

И люди тогда пришли к такой метрике, которая называется эффективность потока, эффективность потока реализации.

Что это такое?

По сути, мы можем взять и просуммировать все чистое инженерное время работы.

Вот эта оценка, когда к вам приходят и говорят «Скажи, вот таска есть, за сколько ты ее сделаешь?» Вы даете какую-то циферку.

Мы берем все эти циферки, складываем их.

Просто складываем.

И потом берем длительность реализации фичи.

И оказывается, что относительно длительности реализации фичи вот эта сложенная оценка трудозатрат, это всего от 1 до 15% всей длительности реализации фичи.

И вот когда такая информация появляется,

Первая реакция на нее такая, да ну не фигня какая-то.

Вот у меня была такая реакция где-то, наверное, году в 2013, ой, в 2016, когда я только сталкивался с этими вещами.

И я пошел перепроверять.

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

Это была одна логистическая компания в Санкт-Петербурге.

Она работает с крупными поставщиками, типа Mars, Procter & Gamble, что-то такое.

И я там взял и происследовал.

И обнаружил, что там 7,5%.

То есть во времени реализации проектов, чисто инженерной работы, 7,5%.

7,5%.

И для меня, например, сразу встал интересный вопрос.

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

Ну, там было 7,5%, ну, сделаю я там меньше.

Пусть у меня там, ну, точнее, 7,5% было, ну, и чисто инженерное время это был месяц.

Ну, сделаю из месяца 25 дней или 20 дней.

Но это всего лишь 7,5%.

То есть сильно на время производства это никак не скажется.

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

Пусть они хорошо работают в свою работу.

А еще знаете, какая замечательная вещь?

А можно, не дергая инженеров, получить прогноз?

И вот здесь и возникает история такая, что...

Работу инженеров нам надо рассматривать чуть по-другому, и прогнозы нам надо рассматривать чуть по-другому.

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

То есть люди опять эмоционально воспринимают эту всю историю, не хотят с ней работать и не хотят ее изучать.

А я бы хотел, чтобы вы все-таки эту историю поизучали.

Не важно, вы сейчас инженер или менеджер, вам это все нужно.

Почему нужно?

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

А еще ему можно, как серый кардинал, этому менеджеру немножко помогать,

И этот менеджер будет его потом тянуть за собой.

Ну и сразу же хочется...

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

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

Тогда что оптимизировать и как оптимизировать?

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

Наверное, того, который справа вы знаете, да?

Он очень популярен в IT-сфере.

Знаете?

Как его зовут?

Голдред, а слева?

Это Тайтиона, да.

Это Тайтиона.

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

Но сами понимаете, господин Голдрет трудился все-таки до 21 века, и это скорее были такие пилотные какие-то истории, которые он пытался развивать.

То есть это не что-то такое сильно развитое.

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

То есть первым самым человеком, который внес идею ограничения количества незавершенной работы, является Таити Оно.

Конечно же, это компания Toyota.

И они у себя вот такую историю использовали.

И там возникает такая штука, которая называется One Piece Flow.

То есть это когда мы делаем такой выстраиваемый процесс работы, в котором у нас...

Есть фокус на одном каком-то рабочем элементе, то есть чем-то, что проходит через производственную систему.

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

Вот многие сталкивались с таким термином, который называется VIP-лимит.

Это и есть ограничение количества незавершенной работы.

Вот по ТАИТИО на этот VIP-лимит равен 1.

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

Кто-нибудь с моб-программированием сталкивался, работал в моб-командах?

Или имеет представление о моб-программировании?

По сути, вы запираете команду аналитиков, разработчиков, тестировщиков в одной комнате.

У них там есть флипчарты, один компьютер.

И они там как бы запираются, их задача запилить какую-то фичу в продукт.

То есть сделать какую-то новую функциональность.

И не важно, что за компом сидит один человек.

Это еще жестче, чем парное программирование.

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

МОП программированный – это чрезвычайно эффективная история, если надо быстро запилить.

Но она просаживает другие вещи.

То есть первая вещь, которую она просаживает, это ресурсная эффективность.

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

То есть один что-то делает, а другие стоят и смотрят.

Ну, условно говоря.

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

Для некоторых бизнесов это критично.

Я не фанат стопроцентной утилизации ресурсов, но у вас утилизация 5%, это не очень сильно годится, и ни один финансовый директор не захочет сделать так, чтобы его вложения, грубо говоря, работали на 5% всего, вложения в персонал.

Но есть другая подноготная у моб-программирования.

Это крайне низкая пропускная способность.

Из-за того, что у вас низкая утилизация ресурсов, у вас крайне низкая пропускная способность.

То есть количество фичей, завершаемых в единицу времени.

У нас есть две метрики.

Одна называется время производства, время, за которое делается фича.

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

И эти две метрики, они зависят от разных вещей.

Время производства очень сильно зависит от количества незавершенной работы, вот от этого параметра, от VIP-лимита.

А вот пропускная способность зависит от количества людей и их утилизации.

И причем сильное ограничение количественной завершенной работы негативно влияет на пропускную способность.

То есть если вы закрыли кран с водой, да, виплемид снизили, количество воды, которое вытекает из этого крана, оно крайне маленькое.

Да, каждая молекула воды вытекает очень быстро, но вытекает объем воды маленький.

И вот это очень сильно надо понимать.

И...

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

То, что потом уже стали называть словом конвип.

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

Потому что есть различные производства, и в различных производствах этот лимит, подходящий под...

запрос клиента о параметрах производства будет разный.

Но в IT-индустрии всё ещё сложнее.

И там появился ещё один человек, которого зовут Дэвид Джи Андерсон.

Это тот человек, который придумал Kanban.

Kanban, который мы используем у себя в IT.

И вот этот человек уже развил эту идею.

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

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

Либо вы работаете итерациями, она у вас разбалансирована, команда таким образом, что в начале итерации умирают аналитики, в конце итерации умирают тестировщики.

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

Работы бывают разного вида, они приходят абсолютно из разных источников.

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

И надо каким-то образом балансировать эту нагрузку.

И получается VIP-лимит вы будете еще и по типизации работ использовать.

И здесь очень важно запомнить некоторые вещи.

Снижение количества незавершенной работы уменьшает утилизацию.

Финализируем то, что я сказал.

Снижение количества незавершенной работы уменьшает пропускную способность системы.

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

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

И еще этот баланс ищется исходя из потребностей.

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

Для кого-то надо делать много и плевать на длительность.

А для кого-то нужен какой-то определенный баланс.

То есть нельзя применить один паттерн ко всем.

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

Копирование – это неработающая история.

Ну и еще один гвоздь в крышку гроба оценок – это то, что оценка – это вероятностная характеристика.

И наброс этот на вентилятор сделал господин Голдред.

То есть, когда к вам пришли и спросили, за сколько вы сделаете эту таску, человек рассчитывает, что вы дадите хорошую оценку.

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

Ну, достаточно с высокой долей вероятности, например, 95%.

Но, получив с 10 разработчиков оценку по 95% вероятности, по задачам, которые должны быть сделаны, например, последовательно, и сложив это время, вы получаете какое-то число.

А вероятность-то как складывается?

По-моему, там корень квадратный суммы квадратов, да?

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

Отсюда идет другая мысль, которую хочется закрепить у вас в голове.

Смотрите, вероятностная характеристика, по сути, прогноз.

А дальше стоит такая история.

А можем ли мы построить прогноз без оценок индивидуальных работ?

Потому что слишком уж как-то сложно получается...

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

Он там пытался делать оценки, отделяя рисковую составляющую оценки от реальных трудозатрат, рисковую составляющую оценки выстраивать в определенные буферы и тому подобное.

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

ну и, кстати, метод критической цепи, проверенный временем инструмент, который входил в стандарт PMBOK аж четвертой редакции.

Вот.

Можем ли мы без вот этого всего обойтись?

Оказалось, можем.

И вот это показал вот этот дядька.

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

Ну, из как бы институтского курса педагога

Теорию вероятности мы обычно помним все, что есть распределение плотности Гауссова.

Такое симметричное.

Шляпа.

Вот.

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

Почему?

Вот как прочитать этот график?

По горизонтали это все возможные время производства.

1, 2, 3, 4, 5.

Вот вы видите.

А по вертикали это количество фичей, сделанное за такое время производства.

Давайте анализировать график слева направо.

Есть столбик трешка.

И там что-то типа 8 фичей были сделаны за 3 дня производства.

Потом идет 4 дня, 30 фичей.

30 фичей было сделано за 4 дня.

51 фича была сделана за 5 дней и тому подобное.

Вот так строится этот график.

На самом деле, мой один коллега называет это технологией каменного века.

Вы берете камешки, раскладываете в кучки.

Камешки – это завершенные уже ваши фичи.

И получается у вас асимметричное распределение со сдвигом влево.

Что это обуславливает сдвиг влево?

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

Вы не можете сделать что-то быстрее, чем за ноль времени.

Вот, соответственно, у вас есть распределение.

У этого распределения есть длинный хвост, то, что уходит вправо.

И вот этот вот хвост...

Но это, в принципе, гадостная история.

Если нужно будет когда-нибудь или в кулуарах, если хотите, я расскажу про то, как бороться с этим хвостом.

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

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

Это факт.

То есть если это факт, то можно по нему сделать прогноз.

И что мы должны сделать для того, чтобы сделать прогноз?

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

А с какой вероятностью ты хочешь получить этот прогноз?

Конечно же, заказчик отшутится и скажет, со стопроцентной вероятностью.

Ну, смотря на этот график, я скажу, окей, 15 дней.

Ну, видите, там последние данные, это 15 дней.

Он мне скажет, Алексей, ты с ума сошел?

Что заказчик будет помнить?

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

Какое здесь самое популярное?

Пятерочка, да, пик.

Это так называемая мода.

Ты же в основном мне все за пять дней делаешь.

Нет.

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

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

И скажу ему другую историю.

Давай делите между собой риски.

И повторю вопрос.

С какой вероятностью ты хочешь получить прогноз?

Ну и тут как бы заказчик начинает обычно чесать репу и выдает что-то там, например, 85%, 90%, 95%.

Допустим, он мне сказал, вероятность 90%.

Что это для меня значит?

Это значит, что в 10% случаев я могу облажаться с оценкой.

Но что это значит для заказчика и вообще в принципе для производственного процесса?

Я беру вот этот график и начинаю справа отсчитывать количество фичей в размере 100-90-10%.

Отсчитываю и получаю, например, здесь 11 дней.

То есть я могу ему сказать, родной, что бы ты мне ни принес, я тебе это делаю за 11 дней.

И тогда мне не надо дергать моих инженеров на оценку,

А тебе не надо вообще даже ко мне ходить, чтобы спрашивать у меня эту цифру.

Ты просто используешь ее как константу.

Мы, может быть, ее пересмотрим через полгода.

Я же все-таки делаю какие-то пассы руками, чтобы оптимизировать производство.

Может быть, я смогу это число изменить.

Но вот до следующего нашего собрания, грубо говоря, ты можешь всегда ставить цифру 11, и это будет норма.

И вот так вырабатывается некоторый SLA.

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

Но поверьте, ребята, вот эта штука и в продуктовой разработке тоже прекрасно работает.

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

То есть мы используем такой термин, который называется...

Тип рабочего элемента, то есть тип того, что нам приходит.

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

Вторая вещь — разные жизненные циклы реализации.

Для каких-то нужно что-то делать, для каких-то нет.

Вот эти будут требовать изменения архитектуры — это не требует.

Вот эти будут требовать изменения структуры базы данных — это не будут.

И чаще всего у вас уже эта типизация есть.

Вы заходите к себе в Task Tracker, и у вас там есть какой-нибудь improvement, feature, story, epic.

Давайте от этого отталкиваться.

И вот этот вот график предыдущий, который я показывал, надо в нем найти, где там improvement, где там story, а где там feature, а где там epic.

И разделить это, чтобы у каждой сущности был отдельный такой график.

И опять же, для каждой сущности найти вот этот 90% и уже подавать по нему оценку.

И ещё очень сильно немаловажная история, это как раз про изменяющиеся приоритеты.

То, что с разной работой мы ведём себя по-разному.

Есть работа, которая, когда появляется, мы ведём с ней себя в режиме «бросай всё и делай только её».

Я уверен, у вас такое есть и случается.

Есть работа, которую мы просто делаем по очереди.

Есть работа, которую мы делаем, когда у нас остаётся время лишнее.

Вот мы такую штуку называем класс обслуживания.

Людской пример класса обслуживания из реальной нашей жизни, самый простой, это эскалатор.

Сервис.

Подняться из метро наверх, на улицу.

Но вы можете стоять справа, а можете идти слева.

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

Это, например, Sky Priority в аэропорту.

Если вы пользуетесь программой Sky Priority, значит, у вас есть отдельный зал, где вы можете подождать.

Вы идете отдельной очередью на регистрацию.

Вы идете отдельной очередью, и у вас приоритетная посадка в самолет.

И также высадка из самолета.

А бывают еще там совсем интересные истории.

Вот, например, в Казани бизнес-зал находится в отдельном терминале аэропорта, и вас даже в самолет везут на отдельном автобусе.

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

То есть просто она получена по-разному.

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

И у нас уже получается матрица.

Тип работ, класс обслуживания, распределение.

И в зависимости от того, что принес заказчик,

тот прогноз ему и можно дать.

То есть как бы простая матрица.

При одном очень важном условии.

Количество незавершенной работы должно быть ограничено.

Но опять же, про это надо все знать достаточно серьезно, поэтому вот эти две книжечки я сильно рекомендую почитать.

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

То есть можно симулировать методом Монте-Карло и находить время, за которое вы сможете сделать какие-то фичи на основании статистики.

Тут стоит сделать небольшую точечку.

Статистики.

А что делать, если у вас нет статистики?

Собирать.

То есть здесь у меня рекомендация такая.

У вас уже есть способ какой-то оценки.

И он как-то у вас работает.

И насколько-то он всех удовлетворяет.

Используйте его.

Я еще причем говорю так, не верьте мне на слово, что оно вот так есть.

Почитайте эти книжечки, попробуйте собрать эту статистику просто отдельно.

Ну есть же у вас какой-то таст-трекер, ну снимите вы эти данные, выгрузите их в Excel, да поанализируйте.

Снимите их.

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

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

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

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

Ну, тебя посчитают токсичным и забанят.

Вот.

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

А влеты всю эту конструкцию могут разрушить.

И поэтому вот эта вся ваша фигня не работает.

И даже оценки тоже не будут работать.

Но на самом деле влеты, это же тоже статистически важная информация.

И вот это распределение, оно учитывало эти влеты.

Только влеты нам надо держать под контролем.

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

Вам стоит проанализировать нагрузку, то есть кто к вам приходит, что приносит за данные.

И при анализе вы выявите, что бывает такая штука, что прывают влёты.

И можно даже посмотреть, сколько статистически этих влётов бывает.

Если у вас были влеты до этого, значит, влеты будут продолжаться.

Мир не поменяется резко.

Мир меняется вообще достаточно инертно.

И заказчики меняются достаточно инертно.

А если влеты есть, то надо просто спроектировать производственную систему с расчетом того, что влеты будут.

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

И если будет появляться влет, то пусть и будет ограничение.

Одновременно вот этих влетов пусть будет не больше двух.

То есть всего у нас емкость системы 22 каких-то рабочих элемента.

Из них два заложены под влеты.

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

Те, кто пользуются, могут рассказать тем, кто не пользуется.

То есть мы проектируем систему, исходя из того, что влеты будут.

И под это целый алгоритм есть.

Я вот здесь привел еще две книжечки.

В синей книжечке про это мало рассказано, а вот та книжечка, которая левее, называется «Канбан from the inside».

В ней это разложено более детально.

Эта книжка, кстати, переведена на русский язык, она называется «Канбан метод».

Ее автор Майк Борроус.

Надо было сюда, наверное, русскую версию книжки, обложку закинуть.

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

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

Там расписан у Майка этот алгоритм, который нужен вам для анализа производственной системы.

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

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

Первая история.

Изучайте менеджмент.

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

И вот эти вот изучить базу по бережливому производству, базу по теории ограничений Голдрета бывает полезно.

И даже почитать работы Тейлора бывает полезно.

Второе, чтобы хотелось бы на чем сфокусироваться, не стоит сразу отвергать новые инструменты.

Инструменты, которые появились в конце, их делали не глупые люди.

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

Потому что все-таки есть у нас на рынке такая история, а, консультант, что он там, теоретик знает, вот мы-то практики, мы вот как бы от Сахи идем.

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

И получается за 10 лет человек сменит, например, 3-4 компании максимум, не по 4 года если отработав, и получает

будет обладать опытом вот этих трех-четырех компаний, то консультант за год сменит 12, и он вам принесет и расскажет.

Вот у этих вот так, у этих вот так, у этих вот так, у этих вот так.

Вот это проблема общая для всех, вот это проблема частная.

Бывает вот у редких компаний.

В этом отличается как бы менеджер и консультант.

Не чурайтесь как бы опыта консультантов, читайте статьи, которые ребята пишут.

В общем, стараются же все-таки для вас, раз они их пишут.

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

То есть вероятностное прогнозирование – достаточно рабочий инструмент.

Собирайте статистику, смотрите.

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

На этом все.

Я точно попал в тайминг.

Чувствуется, что эти методы были применены к докладу.

Алексей, спасибо большое.

У нас пришло время вопросов.

Пожалуйста, господа, у кого есть вопросы, поднимайте руки.

Вот вижу в задних рядах целые две руки.

Алексей, спасибо большое за доклад.

Я ваш тезка из компании Тинькофф.

Вопрос следующего характера.

Так у вас же это используется.

Да, вот как раз поэтому и спрашиваю.

Скажите, пожалуйста, у вас есть какой-нибудь фирменный секрет, чтобы 85-й перцентиль все-таки влево поджимать?

Что на это может повлиять?

Так, давайте немножко всем разъясним 85-й перцентиль.

Здесь есть несколько анекдотов.

Анекдот звучит такой.

Что такое 85-й перцентиль, ребята, то, что говорят в Тиньке?

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

Почему 85-й?

Да потому что кто-то там в докладе сказал 85-й.

Я всегда про то, что говорите с заказчиком.

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

Фирменный секрет поджимания 85-го перцентиля – это работа с буферами.

То есть в первую очередь обратить внимание на буферы, второе – обратить внимание на остановки.

То есть с буферами работа… Ну что такое буфер?

Разработка закончилась, тестирование еще не началось.

Почему не началось?

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

Выровнять баланс в команде, соответственно, сократить размер буфера.

Пусть лучше какие-то люди будут простаивать, но у нас тогда не будет ожиданий каких-то идти.

Вторая история – учитывать остановки.

То есть, грубо говоря, я разработчик, я работаю, я понял, что чего-то не понял, написал письмо заказчику либо аналитику, работу бросил.

Вы трекаете это время, что работа брошена?

Не все трекают это время.

А в этом времени очень-очень много разных полезных вещей.

А еще люди иногда пользуются Task Tracker таким образом, что это время невозможно оттрекать.

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

Как это обычно делается?

Колонка такая называется, постпонит, и туда скидывается задача.

Ну, оно было постпонено на полгода, но по какой причине, я не знаю.

Часто лучше всего как бы пользоваться каким-то трекером, который...

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

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

И пытайтесь их кластеризовать.

Вот это остановка, потому что инфраструктура упала.

Это остановка, потому что соседнюю команду ждали.

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

И считайте общее время.

Вот этот кластер, например, проблемы с инфраструктурой, задержал нас на 103 дня.

Болезни задержали нас на 15 дней, там, не знаю, сами не договорились на 25 дней.

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

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

Это, наверное, фирменный секрет сдвига как бы влево.

Вот это вот, сейчас я покажу.

Что мы пытаемся сделать?

Мы пытаемся вот эту кучку как бы сместить в ту сторону.

Вот эту большую кучу, да?

То есть 85-й перцентиль подвигать.

Ну и дальше как бы стоит вопрос, что делать с хвостами, вот с этой вот частичкой.

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

Так, переходим к следующему вопросу.

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

Продуктовый менеджер Pix Robotics.

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

Как раз хотел аналогичный вопрос задать, но пока отвечали, понял, что надо его интересно задать.

В чем, собственно, вопрос?

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

И вот пришла задача, нас попросили сделать какую-то фичу,

И понимаем, что, в принципе, они без нее пока поживут, и мы ее как раз откладываем, мы пишем себе, что отложили до нужных времен.

А потом, с другой стороны, там сейлы продают, допустим, условно, Тинькову, допустим, мы еще клиенты наши.

И вот сказали, вот они без этой фичи вообще не будут жить, и взяли там через сейлов, завели отдельную вообще задачу.

И получается такая история, что вроде как...

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

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

И такие бывают случаи у нас, когда по 5-6 задач в трекере находятся, когда мы анализируем, что вот это все про одну и ту же фичу,

Ну, у всех разный срок и разное.

Как вы вот это матчите?

Смотри, а ты в этой картинке, я вот упустил вначале, ты продакт или ты… Я продакт-менеджер, да.

Я как раз решаю, когда что мы делаем, и вот некоторые вещи отпадают.

Вопрос такой, я вначале слушал-слушал, думал, если ты как бы delivery-менеджер или project-менеджер, то, блин, какого лешего на тебя приоритизация сваливается?

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

Где, во-первых, это место находится.

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

А еще мне, по-моему, в твоем рассказе прям резанула такая вещь.

У тебя заказчиков много.

Они недоговороспособные.

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

Ну, как бы не о чем, но все пользуются платформой по-разному.

То есть мы делаем платформу, которую все пользуются, чтобы делать автоматизацию.

Вот смотри, а когда происходит вот этот вот влет, то заказчик А может подвинуть задачу заказчика Б. Вот ты бы расписал такой кейс.

Или заказчик А подвигает задачу свою же.

Он свою, которую вы делаете, меняет на новую.

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

Вот это вот вообще жесть на самом деле.

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

То есть сделал бы так называемое револьверное пополнение у вас.

То есть у вас есть заказчик, и у вас есть какая-то… Ну, представим, что ваша производственная система – это револьвер.

У револьвера есть барабан.

В барабане есть, например, 6 комор под пули.

И у вас есть 5 заказчиков.

Один важнее всех.

Вот пол барабана отдайте ему.

То есть он туда вставляет в эти коморы свои пули.

То есть 3 коморы он занимает своими пулями, своими фичами.

Остальные заказчики получают по одной коморе.

Там через один их как-то поставили.

И вот вы стреляете, эти фичи делаете.

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

То есть из-за того, что он более важный, он просто получает больше квот по количеству.

А вот то, что другой заказчик, двигается его фича.

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

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

После этого каким-то образом погасить вот этот негатив и что-то с этим сделать.

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

Ребята, так как вы более важные, вам просто больше квот дается.

Но двигать приоритеты чужих задач вы не можете.

Но это просто нечестно.

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

Но, соответственно, бывает так, что он месяц вообще молчит, говорит, нас все устраивает.

А потом прибегает такой, ой, вот знаете, вот нас вот тут вот вообще...

Сейчас вот там процесс сдавать, а вот без новой фичи вот это не работает.

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

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

То есть пусть команда будет утилизирована не полностью...

Но это как бы просто часть скрипичного мастерства.

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

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

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

Если хотите, я могу так сделать, но, грубо говоря, ко мне потом никаких вопросов по срокам.

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

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

То есть у всех как бы нет искаженных ожиданий.

Если нет искаженных ожиданий, они принимают эту реальность, тогда получается...

Ну, вот так и есть.

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

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

У нас возникает задача, которую мы 5 месяцев делали, а по факту новая задача.

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

Вам окей?

Если они говорят окей, то ладно, мы действуем дальше.

Если они говорят нет, не окей, я говорю, давайте передоговариваться.

Спасибо.

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

Если есть статистика, вы хотя бы можете аргументированно, а не на эмоциях, общаться с ними.

Спасибо.

Так, остается ли у нас в Риме еще один вопрос?

На первом ряду, да.

Да, Алексей, спасибо огромное за доклад.

Я бы хотел попросить у вас совет.

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

Поделитесь, как вы это делаете.

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

Потому что у него есть механизмы сбора данных о блокировках,

И есть механизмы, соответственно, анализа вот этих частотных диаграмм.

О других инструментах я не знаю.

Когда, если вы работаете на западную компанию, грубо говоря, у вас есть доступ к другим, то есть есть аналог кайтона на западном рынке, он называется FlowFast, есть компания болгарская такая, они делают инструмент Kanbanize.

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

Называется, компания называлась Digite, и продукт у них назывался Swift Kanban.

Как он сейчас называется, не знаю.

Но я думаю, можно будет найти в гугле информацию по этому делу.

А всяческие джиры, ютраки, они еще пока так не умеют.

Спасибо.

Друзья, спасибо за ваши вопросы.

Пожалуйста, не теряйте нашего спикера, он будет в дискуссионной зоне после доклада.

Пожалуйста, приходите, спрашивайте, наверняка они все успели.

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

Алексей, еще раз спасибо.

Да, а вам спасибо, что вы выдержали достаточно сложную тему с утра на второй день конференции.