Только мне кажется, что в управлении IT разработкой везде бардак, а если да то как жить дальше?
Публичный пост
Менеджеры
5 ноября 2024
3054
😥 Этот пост был удален самим автором и от него остались лишь комментарии участников. Если вы хотите приютить и развить эту тему как новый автор, напишите модераторам Клуба: moderator@vas3k.club.
Я тимлидю с 2020 года и с тех пор успела повидать разных людей, которые просто не понимают зачем их наняли. Среди программистов такие встречаются особенно часто и я прекрасно их понимаю, потому что сама была такой же.
Такое у нас было, мы успешно с этим справились и теперь все друг друга бьют по рукам/губам, когда в разговоре упоминаются любые детали по задаче. Поскольку слушать эти детали интересно избранному кругу людей, нет смысла тратить общее время на созвоне, чтобы до всего докопаться. Потом все у кого есть друг к другу вопросы - собираются и обсуждают эти вопросы. Но не во время дейлика. Дейлик должен быть прост как две копейки и отвечать на базовые вопросы:
Если начинается какое-то обсуждение архитектуры, то ведущего созвона надо лечить. У нас кстати не запрещено вести созвон кому угодно, кто хочет его вести и показать всем как надо, но почему-то вызывается только два человека, включая меня. Даже если бы созвоны шли не продуктивно, все равно никто не захотел бы ничего менять, потому что рядовым разработчикам интересно решать головоломки другого рода.
Да очень просто. Надо отвечать что можешь лично все рассказать и показать после созвона. Все. Возможно менеджер знает о каких-то подводных камнях и хочет убедиться, что ты не напишешь фигню. Потому что он работает в компании 10 лет, а ты - всего два. И он знает плюс-минус всю кодовую базу своей группы, а ты - пару модулей. В общем, подобные вопросы не всегда означают, что менеджер плох. Могут быть и другие причины.
Но вместо того, чтобы рассказать своему менеджеру как надо сделать или узнать почему д-мо нагромождается, лучше пойти поплакать в Клубе. Я не отрицаю, терапевтический эффект может оказаться достаточным, но если хочется что-то исправить, воевать нужно в другую сторону.
У меня куда чаще встречается ситуация, когда сверху приходят и просят что-то сделать вчера, а через пару недель попыток понять что именно нужно сделать, оказывается, что делать ничего не нужно (по разным причинам).
Это я. Да и не только я. С меня же тоже требуют сроки. И сроки должны быть обоснованными, если с меня спросят срок, а я отвечу "три месяца", мне никто просто так не поверит. Нужны заведенные задачи с объяснением объема работ. Чаще всего вместо этого называется какая-то случайная, но непременно большая цифра из головы.
Кроме того, разве это не противоречит предыдущей проблеме? В ней говорится, что вместо того, чтобы сделать просто, делается сложно. А тут как будто бы менеджер сам предлагает сделать быстрее и проще, разве не так?
Выглядит, на самом деле, так, что претензии в основном к личным качествам лидов, с которыми приходилось иметь дело, а не к самой позиции как таковой. Здесь происходит некоторая попытка выплеснуть свое негодование и найти кого-то с похожими проблемами.
Я тоже могу поделиться своими проблемами, рассказать как это выглядит с противоположной стороны, как раз уже успела навоеваться с самыми разными программистами.
Назовем первого Фёдором.
Фёдору дается задача - написать утилиту, которая будет лезть в архив и доставать оттуда какую-то информацию. Для этого достаточно просканировать каждый файл архива и выдать выхлоп пользователю. Задачка типовая, такие делаются максимум за пару недель.
Что делает Фёдор? Он неделю придумывает логику эвристики, по которой можно из архива достать файлы с информацией каким-то статистически наиболее выгодным способом. Всю неделю он говорит, что задача делается и сообщает на дейликах, что все схвачено, завтра будет готово и помощь не требуется.
Потом он начинает это писать. Появляется гора каких-то общих классов, на которые у него наполеоновские планы, когда-нибудь эти классы будут использоваться в каждой утилите на свете. Примерно неделю он пишет фреймворк для утилиты. За две недели нет вообще никакого работающего кода.
Все это время я смотрю в код и понимаю на что уходит время и одновременно понимаю что я лично сделала бы эту задачу за меньшее время, чем то, которое ушло на общение с этим человеком и попытки уговорить его сделать по-другому.
Задача в итоге делается месяц и чтобы ее доделать мне приходится вмешиваться непосредственно и устраивать сессию парного программирования, чтобы научить человека как делать подобные задачи за вменяемые сроки.
Войны были не только с Фёдором. Есть еще Станислав.
Станислав узнал про какую-то новую фичу. Например, лямбду. И все теперь, весь его код лямбдами просто усыпан. Зачем он это делает? Становится ли код понятнее? Вряд ли. И даже если Станислав уволится, потом всей группе поддерживать написанное. И приходится интересоваться, лезть в мержреквесты и смотреть что в этот раз написал Станислав, не появилось ли новой моды на какую-то другую фичу, не переписал ли он половину стандартной библиотеки под свое видение прекрасного? Он крайне продуктивен и пишет код намного быстрее Фёдора, а значит под свое видение он за пару недель может переписать колоссальное количество строчек кода. А потом это ревьювить. А потом это тестировать. И Станиславу нужно объяснять, что делать так не надо, приводить все эти аргументы, чтобы в следующий раз снова столкнуться с той же самой проблемой уже на другой его гениальной идее.
Еще есть Иннокентий.
Его особенность в том, что он работает в другой группе. И когда прилетает проблема, он всеми силами пытается доказать, что проблема не в коде его группы, а в нашем. Хотя абсолютно по всем признакам очевидно, что проблема на той стороне и это очень легко доказать, а Иннокентий просто поленился разобраться хотя бы чуть-чуть в проблеме и поискать прямые доказательства, потому что это было бы выходом за его зону комфорта.
Есть и другие интересные личности. Программисты крайне иррациональны. В основном потому что чаще всего замкнуты на себя. Многие из них привыкли пилить хобби-проектики месяцами, так и не выпуская никакого релиза. По их соображениям, они получают деньги за то, чтобы решать веселые головоломки. Они могут в открытую говорить, что не хотят документировать и объяснять код. Могут отказываться смотреть клиентские проблемы и считают, что все им должны кланяться за их великие идеи и их воплощения. В особенности эти тупые тестировщики, которые не умеют программировать, а значит - вообще низшее звено в иерархии. А по факту программисты - обычно просто наемные работники, такие же как все остальные. И которым нужно уметь договариваться с другими людьми.
В последнем абзаце я тоже обобщила, конечно. Есть много хороших программистов, и даже Станислав, Фёдор и Иннокентий - отличные ребята, которые иногда делают очень крутые вещи и я рада, что они работают со мной в одной компании, несмотря на их недостатки.
Словами через рот.
Игорь, не пойми меня неправильно, но у тебя в профиле написано, что ты сеньор/архитект. В моём понимании, этот уровень подразумевает не только способность самостоятельно делать задачи, но и способность аргументировать и "продавать" свои решения, а также брать за них ответственность.
Если тебе напроектировали сложного говна, а ты знаешь более короткий и удобный путь, возьми на себя за это ответственность. Всегда ведь можно сказать "Я вижу у нас есть снижение времени разработки в приоритетах. У меня есть иНноВаЦиОнЫе предложения по изменению архитектуры фичи для достижения этой цели без утраты стабильности, мейтейнабили и функциональности. Ответственность беру на себя, готово будет через неделю". Уверен тебя за такое при правильной подаче расцелуют и авторитета ты себе заработаешь.
Не думаю что решать все остальные озвученные проблемы это твоя прямая ответственность, но при этом я в посте не заметил примеров того как ты даёшь обратную связь (и допустим того как она игнорируется). Я могу ошибаться, но у меня сложилось впечатление что ты просто терпишь этот ужас и не выступаешь с предложениями по изменению текущего подхода.
Собственно, на мой взгляд ответ формата "мне кажется рассказ о деталях этого тикета потратит слишком много времени команды, я был бы рад рассказать о деталях всем кому это интересно после дейлика".
Если рассказывать больше нечего, почему бы не сказать "коллеги, я рассказал все детали на довольно низком уровне, если у вас есть какие-то более конкретные вопросы по деталям исполнения, я буду рад ответить".
😱 Комментарий удален модератором...
Хех, когда-то и меня бесило такое. Но я потом взял себя в руки и стал тимлидом. Теперь могу сам
мучать разрабовпрекратить это безобразие в своей команде.Много вижу ответов про софтскиллы и это реально ключевое. Метрика эффективности софтскиллов — получается ли добиваться своего.
Когда я был разработчиком, меня очень бесило для тестеров деплоить код. Я добился словами через рот чтобы мы попробовали научить тестеров деплоить самостоятельно. Было сопротивление: мне никто не верил, тестеры ругались что им не надо дополнительной работы, и вообще всегда тут так работали, но я договорился попробовать. Им всем выдали нужные доступы, я написал инструкции, провел мастер-классы, отвечал на вопросы и терпел недовольство коллег. Было неприятно, бесило что никто не понимает пользы. Но через спринт часть людей отметила, что работать стало спокойнее: тестировщики теперь не зависят от разрабов и не ждут деплоя, а разрабы не отвлекаются на такую фигню. В итоге решили потестить ещё спринт и в итоге оставили и стали жить счастливо.
Вся эта история о том, что можно просто ныть, что «очевидно же, что тестеры должны деплоить», а можно взять на себя ответственность и сделать свою жизнь и жизнь команды лучше. И это требует и времени и мягких навыков
чтобы не быть посланным нахуй.И, кстати, когда у меня был дотошный лид, я всегда готовился к дейлику: выписывал историю коммитов и дополнял деталями, а на дейлике рассказывал без всяких тупняков. Это и на 360 отмечали коллеги, что Женя всегда помнит что вчера делал и красиво об этом рассказывает. Но я не помню. Я просто готовлюсь, потому что дейлик — это часть работы.
И да, коммент получился как будто самолюбование какое-то.
На самом деле я просто не хотел давать прямых советов, а хотел просто рассказать как было у меня. Будем считать что так и есть 😀Отвечу на заголовок поста, не на его текст (не буду комментировать конкретные описанные проблемы, отвечу в общем).
Мне кажется, что "бардак" происходит везде, где применяют методологию управления не соответствующую фазе проекта. Менеджер (как и любой человек) он же не дурак, он хочет чего-то добиться своими действиями. Он книжки читал, опыт имеет...
Но у проектов же разные стадии бывают: RnD, первое тестирование, выход в прод, поддержка и т.п. И те методики, которые подходят для одной совершенно противопоказаны для другой, соответственно и опыт не релевантен.
Например, на RnD как раз нормально мучать разработчика вопросами о том что и почему он хочет сделать, т.к. идёт выбор технологии и подхода, важно не ошибиться.
На первых SIT бесполезно создавать тикеты на ошибки, у тебя будет ломаться всё и везде, команда будет только и заниматься тем чтобы завести и обновить тикеты. Для этого QA и разделяют стадии тестирования: SIT, UAT, FUT и т.п.
После выхода в прод, и особенно миграции (или набора) базы пользователей включаются совсем другие правила.
Иногда надо держать всю команду на звонке пока не починят блокер, иногда надо завести тикет и ждать, не мешать людям работать.
Ох. Больная тема.
По моему опыту, системно проблема лежит в той плоскости, где тимлидов не учат.
Большинство практик управления - это наследственные практики. То есть сталкиваясь с какой-то ситуацией, наш тимлид вспоминает, как действовал его тимлид, и повторяет. При этом копирование практики неизбежно ухудшает её результативность, особенно с учётом того, что копируют то, что заметили, без видения полной картины и без фундаментального понимания всей подкапотной механики.
Вторая глобальная проблема, особенно заметная у начинающих тимлидов - это адаптационный перегруз. Когда новый тимлид заступает на должность - ему приходится адаптироваться к куче новых факторов. И от перегрузки он начинает искать простые решения сложных вопросов.
Поэтому учимся, вырабатываем новые подходы, адаптируемся.
Никогда такого не было. Жёстко ограничиваем 15 мин на дейлик, а после дейлика - время вопросов и ответов, если это требуется.
Тоже не было. Мы обычно с ребятами впиливали костыль, а потом уже я закладывал задачи на "выбивание костыля".
Без сроков невозможно - это да. Поэтому мне пришлось срастить скрам с вотерфол просто потому, что софт B2B, а чистый скрам крайне фигово умеет предсказывать сроки на 6+ месяцев вперёд. Если затык был по оцениванию, то закладывали время на пиление прототипа.
Любопытно, я сам разраб, конечно проблем с процессами много бывает, но то что ты описал часто вижу с другой стороны.
Я недавно делился личным опытом, как стараюсь сейчас это перестроить в венчурной студии - https://habr.com/ru/companies/skl_vc/articles/855676/
Последние 3 месяца мы выгоняли продактов и вместо этого давали разработчикам возможность руководить продуктами и запускать новые.
Естественно только тем, кто хотел и проявил инициативу (устал от менеджента).
Как итог мы перестали платить транзакционные косты на том, чтобы объяснить менеджеру то, во что он слабо въезжает.
В общем объяснить юнит-экономику разработчику или дизайнеру я могу за час. Объяснить разработку продакту за час я не могу
Я работаю много с IT-бизнес управленцами С-уровня и командами (Agile Coach) и сформировала бы проблему так:
если тех менеджмент будет работать не только с техническими вопросами, но и человеческими - вероятно, не нужно было бы нанимать столько других менеджеров. К сожалению, не часто встречаю хорошо развитые софт скиллы и эмпатию у людей, которые спецы в своем деле. И естественно отсутствие доверия или навыка построения доверия создает больше контролирующих органов. А если здесь еще приправить слабым HRBP, который не работает с людьми "как в книжках и должностной инструкции, зачем вообще нужна эта роль", то появляется еще одна прослойка менеджмента :)
Я не знаю как тебе настолько не повезло в жизни, но у меня таких проблем никогда не было :-D
Я рекомендую при выборе работы всегда не только проходить самому интервью, но и очень внимательно интервьюировать будущих работодателей. Я когда искал работу, абсолютно все HRщики, с которыми мы сматчились по культуре, были рады пригласить меня в офис и провести пол-дня с командой — и я так в итоге из трех офферов и выбрал самый классный (хотя по зп он был на 5к меньше самого дорогого).
Одна из сторон работы тимлида — это быть интегратором. Нужно работать со стейкхолдерами, развивать команду, строить план проекта, управлять рисками, закупками и документацией.
Задача менеджера выделить что наиболее важно для проекта, настроить работу в этих направлениях и следить чтобы работа выполнялась.
Под проект надо подобрать подходящие инструменты. Если Скрам помогает проекту, то че бы и нет. Если нужны сроки от разработчиков, сначала надо объяснить как их считать, в каком виде, когда и кому показывать.
Хороший менеджер не берет проектов, под которыми он не может подписаться. Брать невозможные проекты неэтично. То же касается и разработчиков.
По описанным историям, я не вижу чтобы тот тимлид создавал прозрачные правила игры, объяснял их команде и следил за их соблюдением.
А эта ситуация из раза в раз повторяется? Выглядит стрём. И не понимаю, почему это не решается разговорами.
Я лид уже чуть больше года в яше и в целом у нас таких кейсов, я надеюсь, нет. Команда дружная слаженная. По срокам мы всегда исходим от разработки и проработки разработкой (то есть требовать сделать за 2 недели вместо 2 месяцев никто не будет). Если надо быстро, то с продуктом режем объём фич.
Говорить, что именно у тебя в порядке, никто не заставляет. Каждый кусок каждой фичи от продукта проходит через челлендж и вопросы от разработки "а почему мы это делаем? Это правда что-то даст?". И продукт отвечает, потому что заинтересован в полном понимании затеи у всех сторон.
Штука с сервисами, думаю, обоснована какими-то требованиями. Если можешь сделать лучше и быстрее, то можно же донести это лиду и рассказать, сколько вы на этом сэкономите? Или по пути узнаешь, почему именно такое решение принято.
На мой сторонний взгляд, вам не хватает простого человеческого попиздеть. Ну или какой-то из сторон адекватности : )
Мои 5 копеек. Больше 5 лет в большом корпорате прошел от Миддла до Тимлида и такого бардака нет. Есть другие но...
Сейчас как Тимлид я вижу свою задачу доносить таски фичи и процессы до разрабов и помогать если проблемы. По сути мне дейли нужны чтобы понять есть ли проблемы и нужна ли помощь.
Но при этом у нас есть код гайды, процесс гайды и ПР с ревью, на которых я как раз таки проверяю "и обучаю".
При этом да есть да самая проблемы "позволить разрабу делать таск неделю и учиться, хотя сам бы сделал за день". Ну и правильно планировать фичи, особенно по времени.
😱 Комментарий удален модератором...