Когда будет сделано

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

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

Чем более опытный профессионал тем больше буфера заложено в оценку. Потому что лучше выкатить раньше, чем протянуть срок. Здесь кроется первая ошибка. Если вы не допускаете проскальзывания сроков, то ни о каком точном планировании речи быть не может. Вы постоянно будете добавлять буфер, чтобы успеть наверняка. В английском есть идиома to sandbag — дословно — огораживаться мешками с песком. Чтобы защититься от наводнения или пуль.

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

 — 85%, что мы выкатим проект к указаной дате.
 — Клиент вредный, давай по 95% посчитаем. Сколько надо еще времени

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

Выдумывать не нужно. Все необходимое у вас уже, скорее всего есть. 1) Вам нужно знать сколько тикетов в неделю закрывает команда. Для этой статистики нужно брать проектные тикеты, а не все подряд, типа багфиксов. Такой статистики нужно как минимум за 7 прошлых недель. 2) Дальше вам нужно знать сколько тикетов предстоит сделать. Важно, чтобы тикеты были нарезаны в разумном диапазоне и не отличались на 500% друг от друга. 3) Вам нужно знать, сколько всего людей будет работать на проекте минимум и максимум.

Вот и всё.

Если вы хотите улучшить качество предсказания, то желательно добавить 1) время, которое вы тратили на тикеты в прошлом (lead time) и 2) расхождение с планом в прошлых проектах. Иногда начинаешь проект на 10 задач, а заканчиваешь с 40.

Эти данные загружаем в симулятор Монте-Карло. Этот симулятор я подсмотрел в рассылке для менеджеров в Амазоне. Сам симулятор работает прямо в браузере и никуда ваши данные не отправляет.

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

[иллюстрации так же в комментариях]

Таблица вероятности.

График распределения вероятности.

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

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

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

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

Пост: https://teamleadtalks.com/koghda-budet-sdelano/

Вступайте в сообщество.

Если хотите поделиться постом с коллегами на аглийском языке https://www.linkedin.com/feed/update/urn:li:activity:7075587733682839552

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

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

Выпуск выйдет в следующее воскресение. Пока выпуск находится на монтаже предлагаю посмотреть интервью на Senior Software Vlogger.

Мой начальник сказал мне быть менее негативным

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

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

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

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

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

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

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

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

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

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

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

Вступайте в сообщество / пост в блоге / пост на английском

Чем выше мы поднимаемся в должности, тем меньше вокруг нас людей. В терминальном случае — CTO — ты один. Team Lead Talks — это сообщество технических лидеров, менеджеров, людей на управляющих должностях.

https://teamleadtalks.com/munity

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

* В чате сообщества 101 человек
* Присоединилось 5 человек
* Написали 225 сообщений в чате
* Провели 333 минуты на созвонах
* Обсудили 24 темы

Некоторые темы июля
- Что если кто-то в команде работает неполную ставку? Например 4 дня из 5
- Что делать, если в команде нет тестировщиков
- Затронули длительность работы на одном месте в Германии
- Поговорили про проблему миграции с библиотеки Akka и об опасности пренебрежения управлением зависимостями
- Продолжили разговор о код ревью и ответственности
- Как правильно покупать компанию
- Книга Нарративное лидерство
- Большой проект месяцев на 9, который надо сделать за 4
- Отбиваемся от жесткого дедлайна статистикой
- Люди работают не торопясь. Как изменить культуру, чтобы люди работали быстрее, но качественно.
- Уровни программистов, несоответствие человека команде и задачам
- Про горизонт планирования в командах
- Что почитать коммерческому директору, чтобы лучше работать с продуктовой командой
- Стоит ли распределять задачи по программистам и про ньюансы код ревью
- Кейс про большой неповоротливый корпорат
- Маркетинг жалуется, что плохой продукт не могут продать. Продукт говорит, что делали по ТЗ
- Про обучение программированию
- Как часто вы как руководитель признаете, что ошиблись?
- Ответ на вопрос: “Ваше отношение к Diversity”
- Надвигается дедлайн, команда начинает рассыпаться
- Планирование загрузки команды, насколько стоит вмешиваться и останавливать менеджеров?
- Как повышать компетенцию программистов, погрязли в инцидентах
- Столкновение образа мысли стартапа и корпорации
- Кто сокращает, вы сокращаете?

https://teamleadtalks.com/2023-july/

24. Политические игры в IT компаниях

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

https://youtu.be/TMAS5tz6YMg
https://podcasters.spotify.com/pod/show/teamleadtalks/episodes/24-----IT-e2825p4
https://boosty.to/teamleadtalks/posts/a90eea0d-a4da-4d6c-a786-ab85b81af89c

Материалы выпуска 24

Книги:
1. Лестница в небо. М. Хазин, С. Щеглов
2. 48 законов власти. Роберт Грин
3. The Systems Bible. John Gall
4. Dictator’s Handbook. Alastair Smith
5. 7 правил высокоэффективных людей. С Кови
6. Война шимпанзе Гомбе. Джейн Гудолл

Прошлые выпуски:
Системное мышление
Манипуляции управления

25. Религия скрам, эджайл, канбан

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

https://youtu.be/Pz2i1PDMIDc
https://podcasters.spotify.com/pod/show/teamleadtalks/episodes/25-e28ibsl

ПЕРЕВОД: Скрам — это рак.

Я пишу код 25 лет и ничего не делает команду настолько бесполезной как скрам.

Несколько случаев из жизни:

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

2. Если вы хотите быть более эффективным, то должны добавить процесс, а не убрать его. Они заставляли нас принимать участие в “церемониях” — просто модное называние для прорвы митингов: дейлики, груминги, планинги, ретро, скрам скрамов. Мы тратили больше времени на разговоры, чем на дело.

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

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

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

6. Мы измеряли сколько денег стоит выполнить 1 стори поинт и потом подписывали контраты, где клиент покупал пакет 500 стори поинтов.

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

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

9. Мы платили людям, которые говорили нам, жжем ли мы поинты достаточно быстро. Но стори поинты это же мера сложности, а не времени? Уже не важно.

Я верю в Гибкость, но это не гибкость.

Мы привлекли профессиональных скрам мастеров. Мы оплачивали сертификацию людям из нашей команды. Как только мы не пробовали делать скрам. Мы потратили на это годы.

Результат был всегда один и тот же: скрам не работал.

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

Но вишенка на торте это когда проповедники скрама говорят вам: “Если скрам не работает для вас — вы делаете его неправильно Только скрам и работает"

Ну конечно же.

https://twitter.com/svpino/status/1695806027256475777?s=20

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

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

Не сдавай своих директору.

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

Никогда не сдавай своих инженеров директору.

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

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

35-ая неделя. Итоги августа

* В чате сообщества 107 человек
* Присоединилось 8 человек
* Написали 286 сообщений в чате
* Снова провели 333 минуты на созвонах
* Обсудили более 30 тем

Присоединяйтесь! На следующей неделе как раз пройдут созвоны, познакомимся 🙂

Некоторые темы августа
- Задача наладить коммуникацию 5 отделов
- Большая компания, как убедить начальство, что нужно сокращать парк инструментов?
- “Политика" в компаниях
- Есть ли у вас программист, который получает больше вас?
- Никогда не общаюсь со skip level это норм?
- При достижении уровня зрелости бизнеса залочили процессы и контракты сервиса. Это стало тормозить разработку.
- Два проблемных сотрудника на проекте. У одного человека отсутствие мотивации. У второго — череда жизненных неудач.
- Писал документ, чтобы команде продлить сроки по критическому проекту. Документ рассмотрели на высшем уровне и дали дополнительный месяц.
- Пришлось временно взять на себя поддержку. Результат своей работы видно сразу, а в управлении нет.
- Работа в больших энтерпрайз компаниях.
- Талантливый джун как будто немного зарвался.
- Реально ли перейти на англ рынок лидом?
- О чем вы говорите на 1-1
- Перформанс ревью. Неочевидно, как меня менеджера оценивает мой лид
- Оутсорс. Основная метрика - количество людей. Где найти новые возможности?
- Как правильно давать обратную связь, когда человек не проходит собеседование?
- Провели опрос и обсудили кто из на уйти из менеджмента обратно в программирование
- Управление Тех долгом
- Попадание в оценки задач