[СММ-2024] Предпочтения и интересы

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

Цифры озвучены: “сделано одна четвёртая задачи из беклога (из всех задач на год), принято решение за третий квартал добрать 30% людей, чтобы успеть доделать всё, что осталось”.

Интересная математика. Из соседних блоков кто-то задал вопрос, которым многим пришёл в голову: “Как добавление трети людей, может помочь за половину времени сделать оставшиеся три четверти работы?” Два плюс два равно семь.

Мой вечный вопрос к менеджменту никто не задал: “Неужели никто не понимает, что изменения отложены во времени?”
Ладно, что этих людей ещё надо найти. Потом они будут две недели оформлять документы, получать доступы и технику. И в принципе все три месяца испытательного срока они будут кое-как въезжать в новую предметную область, в довольно большой продукт. Т.е. даже если взять нашу команду по стэку, у нас три сервиса. Кодовая база объёмная и довольно сложная. Я прекрасно помню, как проходил мой испытательный срок. Ты приходишь, (нанимали на собеседовании Elixir разботчика) и тебе знания языка программирования не помогают вообще. Т.е. условно тебе нужно 30% знаний языка программирования и 70% знания предметной области. Чтобы что? Ударить молотком ровно туда, куда нужно, за пять минут. Иногда даже если знание предметной области есть, место куда нужно ударить, надо пару часов искать. Но когда знания домена есть, ты хотя бы знаешь, где искать. Когда только пришёл, не знаешь, не можешь знать.

Сколько нужно времени на онбоардинг нового разработчика? Нет простого ответа на этот вопрос. У нас команды поделены сейчас вроде даже “красиво”: по DDD. Т.е. каждая команда отвечает за часть продукта именно бизнесовую часть. Вот есть команда “Выплаты”, а есть команда “Налоги и взносы” и т.д. Я в выплатах освоилась месяца через два, после того, как сама реализовала большую “фичу”. Т.е. как-то меньше четырёх месяцев до реальной пользы не получается. Какие-то микроштуки человек начнёт делать сильно раньше 4х месяцев. Вопрос ещё в том, а есть ли у нас эти простые штуки на реализацию. Вполне может оказаться, что их нет, есть только сложные. И там дальше я много могу написать.

Если не быть заведомо знакомым с трудовой/ производственной культурой, то придётся тяжко: действия людей в проекте будут казаться непросчитываемыми, случайными. Но это не так. Действия людей (то есть работы по каким-то методам) происходят «в ролях», они абсолютно не случайны, их легко предсказать.

И тут меня немного попустило. Хорошо, скорее всего я думаю, как разработчик. А чтобы понимать менеджера, надо думать, как менеджер. А у менеджера что? У менеджера обязательства и сроки. И если сроки названы, то в них надо укладываться. И мыслит он ресурсами. Не хватает ресурсов, давайте их добавим. Мыслит ли менеджер оптимизациями методов работы? Мне как разработчику всегда кажется, чтобы производительность выросла, нужно оптимизировать (это значит убрать препятствия, взять какую-то более эффективную штуку, как минимум пойти и разобраться, а почему стало медленно). Можно ли такой процесс делать с целой организацией? Да наверно можно. Но “некогда точить пилу, пилить надо”. Либо у меня слепое пятно, а это делается где-то выше по уровням. Я просто не вижу. Хотелось бы верить, что это так.

Оставим верхние уровни в покое.

Как выглядит спускание сроков со стороны разработчика. Выглядит так себе. Я про это ещё в начале МиС писала (в начале года). Есть важный функционал. Все про него знают. И мы его не делаем. Мы его не делаем, не потому что сейчас есть что-то более важное. По крайней мере опять же на уровне команды это выглядит именно так. Мы не делаем, потому что не готово. Сначала не готова методология. Это окей, методология это сложно. Методолог (когда он один) очень сильно занят и с трудом успевает делать всё, что от него хотят. Доделали (вроде) методологию. И снова ничего не происходит. Теперь мы ждём аналитику. Сроки в этот момент продолжают протухать. Настоящие сроки разработка не знает (внимание!) никогда. Вот аналитику я уже могу подозреть в “плохих методах работы” или “незнании методов работы”. И ещё во всяких других грехах. Но конечно есть нюанс. В учебнике сказано, что люди крайне изобретательны. И интересы у них есть не только ролевые, но и личные. А среди личных вполне могут оказаться “не получить по шапке от начальника”, “перекинуть ответственность на кого-то другого”. И что-то подобное как будто происходит. Бизнас анализ стал ждать прихода в команду системного аналитика. Зачем? Потому что “не моя экспертиза”. Как мы полтора года жили без системного анализа, никто не помнит. Почему нельзя системный анализ делать разработчику, никто не знает. Регламент. Нарисовали схему в команде должен быть СА. А его что? Правильно, надо сначала найти. А потом то, что я писала про четыре месяца онбоардинга. А ещё он может уволиться в середине испытательного срока. Начинай сначала. А время на его бесполезное обучение потрачено. Обратно не вернёшь. Выноси готовенького, кто на новенького.

Подходим к кульминации рассказа.

Сейчас лето. И протухающие сроки кажется подошли к критичной черте (т.е. к настоящим срокам). И теперь от разработки будут требовать “оценку сроков”. Можно от разработки требовать оценку сроков, когда функционал большой и его даже непонятно, как делать? Конечно можно. Обычно для этого есть “абстрактные кони в вакууме”, они же сторипоинты. Но это когда у вас процесс идёт по Скраму более-менее “по учёбнику”. У нас он не идёт. Нужно будет что-то типа “А за две недели сделаете? нууу. Ну за три точно должны сделать! Отказы не принимаются.”

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

Нужно больше трудового кругозора.

7 лайков

ну так, 9 женщин, если как следуют постараются за месяц управятся))

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

Так а что делать по итогу?)

“Вскрытие показало, что пациент умер от вскрытия”. Временем всё проверится.

Я не знаю уже у кого спрашивать и что толку это спрашивать. В разработке всегда есть два инструмента управления ситуацией “мы не успеваем”: 1) докинуть людей 2) порезать функционал.

  • Брейн, а что мы будем делать сегодня вечером?
  • Тоже, что и всегда. Пытаться захватить мир.

Будем пытаться изменить мир. К лучшему.

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

2 лайка

Это цитата? У меня ощущение, что Брейн всегда хотел что-то взо… хлопнуть :slight_smile:

Цитата.

Gee, Brain , what do you want to do tonight?
The same think we do every night, Pinky - Try to take over the world!

Мне довольно близко написанное в посте. Иногда я обсуждаю эти вопросы с кем-то из (дружественных) коллег за обедом, но чаще обдумываю и переживаю наедине с собой. И это самое интересное, потому что всегда “в расследовании выхожу на самого себя”. Дескать, что лично я мог бы сделать? И почему этого не делаю? Получив внутри себя ответы на эти вопросы, на время успокаиваюсь (хотя, это редко бывает приятно).

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

Проходила я это в разных фирмах. Как сказать. Это оптимизация по части менеджмента. Точнее это попытка настроить метрики, по которым можно будет сделать некие выводы. Метрики (не только менеджерские) ненадежны сами по себе. Чтобы они работали их нужно правильно выбрать и дальше там много вопросов о причинно-следственных связях, которые не всегда задаются. И к сожалению вот эти переходы по статусам задач вообще никак не отвечают на вопрос “а мы делаем то, что изменит мир к лучшему?”. Мы то делаем, что нужно? Я сколько угодно могу оптимизировать зависание задач в статусе “code review” или “ready for test”. Скорость переходов по этим статусам, хоть что-то мне говорит о качестве тестирования и нужности взятой в работу в задачи? Нет, не говорит.

Это менеджерские приколы про прозрачность. Во-первых, “мы хотим видеть что вы делаете прямо сейчас”. Во-вторых, “мы хотим видеть, что вы не бездельники, т.е. двигаете карточке по доске достаточно часто”. А ещё это оптимизация на выходе (идём перечитывать МиС), что уже довольно часто “поздно и дорого”. Если мы криво напилили задачи, оценили, что сделаем за две недели, а не можем сделать за три. То наверно метрика это покажет к концу месяца.

На менеджеров (даже у которых плохо с математикой) очень хорошо действуют картинки с графиками. У нас была похожая ситуация: нужно сделать фиксированный скоуп к конкретной дате. Когда мне уже было понятно что не успеваем менеджмент от моего нытья ещё продолжал отмахиваться. Тогда я сделал график сгорания задач из беклога по оценённому времени. Синяя линия - это фактически потраченное время, зелёная - это идеальная модель как время должно было тратиться чтобы успеть к намеченной дате, жёлтая - это модель расчитанная на основе того сколько команда в среднем съедает времени. Благодаря этому получилось заранее договориться немного сдвинуть дату релиза и выкинуть ненужные таски из беклога.

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

2 лайка

Есть вот такая прекрасная тула GitHub - rodrigozr/ProjectForecaster: Forecast probabilities of a project's effort and duration using Monte Carlo simulations
Делает ± то же самое но представляет чуть больше ручек: например - 90% что закончим в сентябре или 40% что успеем к августу, чего хотите?

2 лайка

Хотя и согласен с некоторыми (многими или даже всеми) тезисами, в целом я вижу все чуть иначе. Вопрос “Делаем ли мы мир лучше?” меня не беспокоит – очевидно, что да: деньги-то мне платит компания, а ей - клиенты, а им - их клиенты, значит ценность какая-то есть для все в цепочке :slight_smile:

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

Для закрытия неудовлетворенностей рабочим процессом надо как-то этот процесс менять. Не факт, что после первого (i-го) изменения неудовлетворенности исчезнут, поэтому изменения должны быть постоянными – нужен процесс по изменению процесса (разработки в данном случае). Вот за что борьба, потому что менять на практике мало кто готов, тем более постоянно :slight_smile:
Колоться, но продолжать есть кактус более привычно.

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

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

На самом деле работа с неудовлетворённостью может быть очень разная. Начиная от того, чтобы уточнить неудовлетворенность. “Мне не нравится как мы работаем” это плохая формулировка. “Не нравится процесс разработки” тоже. За любые изменения есть цена и как вы правильно заметили, не то, чтобы кто-то что-то хочет менять. Деньги то ходят туда-сюда. Зачем? А когда будет уточнена неудовлетворённость, можно будет попытаться подобрать методы для решения проблемы. А потом посчитать стоимость изменений по этим методам. И вполне может оказаться, что задача “внедрить в компании sota методы работы системной инженерии” штука неподъёмная. И проще пойти выучиться на какого-нибудь барбера и приносить людям понятную пользу, получать быструю и реальную обратную связь от довольных клиентов. А не вот это вот всё.