После очередного квартального собрания задаюсь вечными вопросами. “Кто виноват и что делать?”
Цифры озвучены: “сделано одна четвёртая задачи из беклога (из всех задач на год), принято решение за третий квартал добрать 30% людей, чтобы успеть доделать всё, что осталось”.
Интересная математика. Из соседних блоков кто-то задал вопрос, которым многим пришёл в голову: “Как добавление трети людей, может помочь за половину времени сделать оставшиеся три четверти работы?” Два плюс два равно семь.
Мой вечный вопрос к менеджменту никто не задал: “Неужели никто не понимает, что изменения отложены во времени?”
Ладно, что этих людей ещё надо найти. Потом они будут две недели оформлять документы, получать доступы и технику. И в принципе все три месяца испытательного срока они будут кое-как въезжать в новую предметную область, в довольно большой продукт. Т.е. даже если взять нашу команду по стэку, у нас три сервиса. Кодовая база объёмная и довольно сложная. Я прекрасно помню, как проходил мой испытательный срок. Ты приходишь, (нанимали на собеседовании Elixir разботчика) и тебе знания языка программирования не помогают вообще. Т.е. условно тебе нужно 30% знаний языка программирования и 70% знания предметной области. Чтобы что? Ударить молотком ровно туда, куда нужно, за пять минут. Иногда даже если знание предметной области есть, место куда нужно ударить, надо пару часов искать. Но когда знания домена есть, ты хотя бы знаешь, где искать. Когда только пришёл, не знаешь, не можешь знать.
Сколько нужно времени на онбоардинг нового разработчика? Нет простого ответа на этот вопрос. У нас команды поделены сейчас вроде даже “красиво”: по DDD. Т.е. каждая команда отвечает за часть продукта именно бизнесовую часть. Вот есть команда “Выплаты”, а есть команда “Налоги и взносы” и т.д. Я в выплатах освоилась месяца через два, после того, как сама реализовала большую “фичу”. Т.е. как-то меньше четырёх месяцев до реальной пользы не получается. Какие-то микроштуки человек начнёт делать сильно раньше 4х месяцев. Вопрос ещё в том, а есть ли у нас эти простые штуки на реализацию. Вполне может оказаться, что их нет, есть только сложные. И там дальше я много могу написать.
Если не быть заведомо знакомым с трудовой/ производственной культурой, то придётся тяжко: действия людей в проекте будут казаться непросчитываемыми, случайными. Но это не так. Действия людей (то есть работы по каким-то методам) происходят «в ролях», они абсолютно не случайны, их легко предсказать.
И тут меня немного попустило. Хорошо, скорее всего я думаю, как разработчик. А чтобы понимать менеджера, надо думать, как менеджер. А у менеджера что? У менеджера обязательства и сроки. И если сроки названы, то в них надо укладываться. И мыслит он ресурсами. Не хватает ресурсов, давайте их добавим. Мыслит ли менеджер оптимизациями методов работы? Мне как разработчику всегда кажется, чтобы производительность выросла, нужно оптимизировать (это значит убрать препятствия, взять какую-то более эффективную штуку, как минимум пойти и разобраться, а почему стало медленно). Можно ли такой процесс делать с целой организацией? Да наверно можно. Но “некогда точить пилу, пилить надо”. Либо у меня слепое пятно, а это делается где-то выше по уровням. Я просто не вижу. Хотелось бы верить, что это так.
Оставим верхние уровни в покое.
Как выглядит спускание сроков со стороны разработчика. Выглядит так себе. Я про это ещё в начале МиС писала (в начале года). Есть важный функционал. Все про него знают. И мы его не делаем. Мы его не делаем, не потому что сейчас есть что-то более важное. По крайней мере опять же на уровне команды это выглядит именно так. Мы не делаем, потому что не готово. Сначала не готова методология. Это окей, методология это сложно. Методолог (когда он один) очень сильно занят и с трудом успевает делать всё, что от него хотят. Доделали (вроде) методологию. И снова ничего не происходит. Теперь мы ждём аналитику. Сроки в этот момент продолжают протухать. Настоящие сроки разработка не знает (внимание!) никогда. Вот аналитику я уже могу подозреть в “плохих методах работы” или “незнании методов работы”. И ещё во всяких других грехах. Но конечно есть нюанс. В учебнике сказано, что люди крайне изобретательны. И интересы у них есть не только ролевые, но и личные. А среди личных вполне могут оказаться “не получить по шапке от начальника”, “перекинуть ответственность на кого-то другого”. И что-то подобное как будто происходит. Бизнас анализ стал ждать прихода в команду системного аналитика. Зачем? Потому что “не моя экспертиза”. Как мы полтора года жили без системного анализа, никто не помнит. Почему нельзя системный анализ делать разработчику, никто не знает. Регламент. Нарисовали схему в команде должен быть СА. А его что? Правильно, надо сначала найти. А потом то, что я писала про четыре месяца онбоардинга. А ещё он может уволиться в середине испытательного срока. Начинай сначала. А время на его бесполезное обучение потрачено. Обратно не вернёшь. Выноси готовенького, кто на новенького.
Подходим к кульминации рассказа.
Сейчас лето. И протухающие сроки кажется подошли к критичной черте (т.е. к настоящим срокам). И теперь от разработки будут требовать “оценку сроков”. Можно от разработки требовать оценку сроков, когда функционал большой и его даже непонятно, как делать? Конечно можно. Обычно для этого есть “абстрактные кони в вакууме”, они же сторипоинты. Но это когда у вас процесс идёт по Скраму более-менее “по учёбнику”. У нас он не идёт. Нужно будет что-то типа “А за две недели сделаете? нууу. Ну за три точно должны сделать! Отказы не принимаются.”
Смотрела схему организации всей нашей большой команды продукта. Оргзвена, которое выпускает ту самую информационную систему. Есть ощущение, что в функциональной команде пропущена роль менеджера. Того самого, который в отличие от аналике не просто принесёт “надо вчера”, а как-то повлияет на то, чтобы разработка запустилась и двигалась, разрулит препятствия. Может быть верхний уровень думает, что бизнес анализ выполняет эту роль, раз сроки им спускают? Непонятно.
Нужно больше трудового кругозора.
