Ниже представленные правила, наверное, должны немного корректироваться вместе с рангом: я пишу из позиции линейного руководителя (тимлида), который управляет непосредственно исполнителями (разработчиками и тестировщиками). Скорее всего, на уровне топ-менеджмента есть свои важные нюансы. Однако в общем и целом идеи останутся теми же.
Первое. Не теряйте ответственности по дороге
Всю дорогу стараюсь донести до своих разработчиков мысль, что задача (таск в Джире) — это их зона ответственности вплоть до попадания кода в прод. Хотя деплоит в прод за редким исключением не разработчик.
Антипример.
— (на дэйлике) Разработчик Васенька, скоро уж страшный зим катит глаза, в смысле, окончание спринта, что у тебя вот с тобой задачкой на 6 человеко-часов?
— Ой, а я же тебе на позапрошлом дэйлике сказал, что Луна в Третьем доме, поэтому на неё забил…
— (немая сцена)
Что пошло не так? Исполнитель неявно спихнул ответственность за свою часть работы на руководителя: пусть Папа Римский помолится за всех нас! Не произошло явной передачи (это когда обе стороны понимают, кто теперь тащит задачу, и фиксируют договорённость где-то, хоть в той же Джире). У подчинённого возникла иллюзия, что если он проговорил вслух о своей проблеме, то добрая фея уже прилетела и всё решила за него.
Кстати, а почему я написал «вплоть до попадания кода в прод», хотя программист не деплоит сам? — По мере выполнения задачи могут возникать тонкости, которые знает только сам исполнитель, такие как:
— нужно не забыть добавить переменную в env;
— нужно выполнить команду на серваке и ещё запустить крон;
— нужно к деплою подготовить фича-ветку так, чтобы в ней были самые последние изменения из master, иначе в день деплоя по чатам будут летать сообщения на тему «Срочно исправь конфликты в своей ветке!»;
— нужно увидеть результат своей работы в проде и получить порцию дофамина.
Второе. Старайтесь не общаться с марсианами
Этот пункт развивает мысль, начатую в первом. Иногда, особенно при разборе какого-то факапа, разработчик начинает говорить о задаче отстранённо: «в коде появилось...», «в ветку влилось...», «в прод залили...». Мой руководитель иногда перебивает такое повествование вопросом: «Кто, марсиане залили?»
У любого явления внутри компании всегда есть объект и субъект. По умолчанию ожидается, что в пределах своей зоны ответственности вы являетесь субъектом. В некоторые моменты разработчику может показаться, что он на мало что может повлиять, что все шишки сыплются на него не очень справедливо, и уходит от психологически неприятной ситуации вот таким способом — обезличиванием поступков.
Гораздо продуктивнее сразу обозначать, кто на ком стоял: мол, вот я поступил так, а Вася сделал так, а потом пришёл директор по продажам
— говорите о делах, не давайте сразу эмоциональные оценки людям, пока это не станет уместно (ну это самая банальность про общение);
— при необходимости опирайтесь на установленные правила, процедуры, письменные договорённости (и вам станут отвечать взвешенней, и вы сами ещё раз проанализируете свой поступок, больше станете понимать, что именно пошло не так).
Маленькое отступление. У меня был один подчинённый, который при разборе неочевидных коллизий на работе вдруг переходил «на вы», то есть начинал говорить в духе «у вас тут в компании...» и «ваши сотрудники сделали...», хотя в обычной ситуации вполне себе употреблял местоимение «мы», да и вообще уже давно работал в команде.
Из этих двух пунктов логично вытекает следующий.
Третье. Вместе с жалобой приносите проект решения
Конечно, эмоции важны, и совершенно естественно прийти к руководителю со словами «да конём оно...», в смысле «мсье, я обескуражен наметившейся тенденцией». Но ведь вы не только хотите спустить пар, но и, как ответственный исполнитель, решить проблему? — Тогда помогите своему руководителю (самые хитрые тут даже начинают направлять его усилия в нужную им сторону не только по поводу одной задачи, но это отдельное искусство)!
Если мы говорим про IT, то в уме держим две важные предпосылки:
1) Тимлид часто не техлид, особенно в кросс-функциональных командах. Соответственно, мгновенную техническую экспертизу вы от него не получите. Более неуверенный тимлид попытается что-то сказать с ходу, «чтобы не выглядеть дураком». Более опытный, возможно, скажет, что нужно подумать, создаст встречу, привлечёт других людей.
2) У тимлида на сегодня, завтра и в любой другой день на порядок больше задач, чем у исполнителя. Это не преувеличение, кстати. При переходе на уровень руководства командой количество ежедневных дел, причём совершенно разноплановых, возрастает раз в 10. Поэтому даже если тимлид попытается вас понять без предпосылок и собственного исследования вопроса, не факт, что хватит его ментального ресурса.
Одно дело, когда мы прохожему на улице задаём вопрос «Как пройти в библиотеку?», а он отвечает что-то грубое: может, его уволили сегодня, или любимая команда проиграла. Другое дело, когда мы все работаем в коллективе, и примерно знаем, как оно есть на самом деле. Так вот, во втором случае каждый раз подходить за решением вопроса совершенно неподготовленным — это верный способ заставить злиться на себя.
Кстати, немного отступая: этот совет универсален для любого общения на работе, не только с руководителем. Одно дело, когда человек просит коллег помочь ему, просто пуская пузыри со словами «я ничего не понимаю» (читай: сделай-ка ты, коллега, за меня мою работу!). Другое дело, когда поясняет, что сделал 1-2-3, тут прочитал, там узнал, но вот именно тут и тут (показывает пальцем) не хватает каких-то важных знаний. Значит, такой человек уважает коллег и не собирается тратить их силы и время на то, что может сделать сам.
Из третьего пункта ещё более логично вытекает четвёртый.
Четвёртое. Руководитель — ваш рычаг, ваш бустер, ваш джинн из бутылки
Частенько люди пишут, мол, я что, нанимался ещё и требования писать, и код тестировать? Я хочу, чтобы мне просто приносили ТЗ, а я просто пилил код, отстаньте от меня все!
Я уважаю такую позицию: есть много людей, которые не хотят развиваться, выходить за однажды установленные кем-то рамки. Им нужно дать возможность работать согласно договора / контракта с фирмой, и поставить нормальный рабочий процесс — прямейшая обязанность руководителя.
Однако, если вы задумываетесь над саморазвитием, ростом куда-то вверх, вбок или вглубь, вам просто интересно что-то поменять, то ваш первый и главный союзник — не курсы по прокачиванию чакр, не джобхоппинг и не личная суперхаризма, а именно ваш руководитель. Поднесите ему идею, заразите сомнением, дайте намёк на решение, наконец, сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас, а влияния в компании у него больше!
Мало того, открою маленький секрет: как правило, руководители сами молятся, чтобы в их команды попадали инициативные, неравнодушные люди. Пытаются понять, как увидеть таких на собеседованиях. Только пожалуйста, не путайте это с поиском «молодых с горящими глазами» (и готовых работать за полцены). Нет, тут всё максимально рационально: часто готовы поднимать людям зарплату, давать премии, растить внутри компании, но лишь бы сам человек показывал, что он этого хочет.
Причина таких ожиданий простая: с одной стороны, IT слишком сложная отрасль, и руководитель просто физически не может во всём разбираться лучше всех. С другой, всё ещё открытая экспериментам. Давайте честно, эксперименты в IT стоят фантастически дёшево: ну, не тот фреймворк прикрутили, ну потратили два месяца впустую. Это совершенно не то же самое, что поиграть в модернизацию в фармацевтике или авиастроении. Отсюда, кстати, незарегулированность IT: у нас и нормальных отраслевых стандартов до сих пор нет, и мы до посинения спорим, кого считать сеньором, кого джуном.
Поэтому когда человек показывает, что в пределах своей поляны он готов развивать себя, свою часть продукта и через это всю компанию, а не просто превращать ТЗ в JSON'ы — он welcome вери мач! Да, вы можете привести кучу примеров, когда компании это нафиг было не нужно. Но всё же, сначала попробуйте сделать своего руководителя союзником в деле своего профессионального роста. Ну а если попробовали и поняли, что тут тухло — тогда уже бегите.
Пятое. Доверие — основа общения
И наконец, пункт, который говорит о базе, на которой строится взаимодействие. Тут не про его осуществление, а про подготовку. Люди, как и все другие социальные существа, постоянно «обнюхивают» друг-друга, то есть стараются построить более-менее точную картину насчёт того человека, с кем они имеют дело.
Вы можете влиять на то, как вас воспринимают ваши коллеги, и можете отдать это на волю случая. Если второе, но вам надо, чтобы ваш руководитель был таким же гением коммуникации, как Костик Ромин из «Покровских ворот», либо рано или поздно может возникнуть недопонимание.
Может быть, вам проще на встрече 1-1 буркнуть что-то вроде «Всё нормально, я пошёл», но вам же лучше, если вы поделитесь о том, что вас волнует, с руководителем. Может быть, вам кажется, что ваше лицо по утрам не очень, и вы сидите на дэйлике с выключенной камерой, когда все остальные коллеги с открытыми лицами. Но у людей подсознательно будет возникать ощущение, что «он какой-то не такой, что-то скрывает».
Если не особо тянет общаться, и вы просто интроверт, который любит решать задачки, рассматривайте это как инвестицию в свой личный комфорт. Вы сообщаете о себе немного, но достаточно, чтобы руководитель (и другие люди) строили коммуникацию с вами так, как выгодно вам. Может быть, вы в реальности не прогульщик, который в 14 часов в пятницу уже сбежал с работы, а добрый внук, который правда ездит ухаживать за своей старенькой бабушкой. Но сделайте так, чтобы это было понятно! Привычки, личные границы, ваш стиль — гораздо лучше, чтобы обо всём этом ваш руководитель узнал непосредственно от вас, чем додумал сам. В конце концов, все руководители — тоже обычные люди со своими фильтрами восприятия. Просто на них халат накинули раньше.
В завершение. Может показаться, что это какой-то там тимлид решил поумничать и полечить разработчиков, какими им следует быть и что делать помимо перекладывания ТЗ в код. Однако все эти советы я в равной степени примеряю и на себя. Тимлиды так же должны стараться общаться со своими руководителями отделов, направлений, а те — со своими техдирами.
Коллеги, если в комментарии вы дополните мои правила своими и подкрепите их примерами, будет замечательно!
Комментарии (44)
Informatik
20.11.2024 20:43Чтобы исполнители были более ответственные труд должен быть организован так чтобы он способствовал появлению этой ответственности.
Руководство часто забывает, что оно работает с людьми, а не роботами и пытается превратить все в самоходную систему. Чтобы уменьшить bus-фактор и облегчить себе распределение работы руководство часто обезличивает исполнителей, лишая их специализации на одном элементе системы. Принцип - все должны работать над всем. Если завтра Вася свалит в закат, то Петя сможет делать его работу, поэтому Петя должен каждый божий день мониторить и мириться с тем что наделал Вася. Петя универсальный солдат. Очень удобно для менеджера. Показываешь команде таких универсалов кучу работы и говоришь "Фас! Сделайте мне красиво!" Они там сами разберутся. Не надо париться с тем чтобы искать работу исполнителю потому что всегда какая то работа есть и не надо париться с тем чтобы искать исполнителя на эту работу.
Я как исполнитель могу сказать что я был бы более ответственным если бы мне дали мотыжить свой участок. Когда над одним участком кода работает много людей, то очень трудоёмко становится ежедневно удерживать понимание того как это все работает. Не секрет, что читать код сложнее, чем писать. Каждый раз как в первый раз приходится заново исследовать, а как же теперь работает этот чёрный ящик. Такое глубокое исследование должно делаться один раз в начале работы, а потом каждый день человек маленькими усилиями развивает модуль. А если приходится постоянно заниматься такой деятельностью то это способствует выгоранию. И вообще это какой-то абсурд, когда команде как коллективному целому постоянно приходится реально изучать, разбираться с тем, что эта же команда наделала. Т.е. мы не понимаем, что мы делаем?! Ладно там если люди увольняются, то надо разобраться с их наследием, но почему я должен каждый день до ночи вникать в детали их реализаций?! Я взрослый человек и кроме работы у меня еще другие могут быть интересы в жизни.
К тому же другие люди часто расширяют код нет так как это бы сделал я, с чувством, с толком, с расстановкой. Особенно раздражают гастролеры, которым лишь бы воткнуть куда-то что-то не в тему и не в систему лишь бы быстренько закрыть свою задачу и побежать дальше с высоким KPI, а мне потом возиться с этим.
Другой момент это то, что программировать это не всегда типовая работа. У человека который печёт пирожки все понятно, только делай. В программировании же часто приходится решать задачи в которых надо придумать решение. Я реально не могу дать оценку сколько времени на это уйдёт: день, неделя, месяц или вся жизнь.
botyaslonim Автор
20.11.2024 20:43Есть же простое решение: открыть свою фирму и писать свой код. Тогда вам никто не будет говорить, что надо делать.
Либо это звучит как "кладите мою зарплату в тумбочку и отвалите, я занимаюсь тем, что мне нравится".
Informatik
20.11.2024 20:43Тоже верно. Но я считаю, что мы разработчики должны бороться за создание более дружелюбной среды для "разрабов", как нас называют. Собственно поэтому я это все и написал тут.
botyaslonim Автор
20.11.2024 20:43Я же сам был разрабом лет 10, у меня были хорошие тимлиды, но чаще посредственные или плохие. Я стараюсь быть для своих разработчиков хорошим.
kitchip
20.11.2024 20:43Я бы сказал, звучит не банально. Но в перемешку вредные и полезные советы :)
botyaslonim Автор
20.11.2024 20:43А какие вредные?
kitchip
20.11.2024 20:43Пункт 4. Инициативность. Быть инициативным себе дороже. Рост зп не соответствует росту прилагаемых усилий, проверено не единожды. Повышение денег на уровень инфляции - не является повышением ;)
А вот джопхопинг до какого-то момента является лучшим способом расти на 30-40% в год. Примерно до 550к нет в месяц(на данный момент), затем уже можно начать задумываться о: смещение фокуса в другие области, каминг-аут в менеджеры/лиды, валютные удаленки. Но во всех вариантах надо очень аккуратно считать профит и потери
Пункт 5. Доверие. Какой-то процент его должен быть, но не 100%. Всё-таки цели линейного работника и его начальника, обычно, различаются.
С остальным полностью согласен.
botyaslonim Автор
20.11.2024 20:43Про п.4 я сразу предполагал, что его поймут не только лишь все :)
Да, джобхоппинг в среднем был проще до недавнего времени. Но бывают случаи, когда и компания хочет разработчику что-то интересное дать, и разработчик хочет больше денег и статуса, а у них ничего не получается из-за сущей ерунды - они просто не начинают говорить об этом. И в последнее время, кмк, это станет актуальнее в связи с кризисом в экономике и тем, что программистов, кажется, на рынке труда становится больше, а вакансий меньше.П.5 да, полного доверия не будет, как и дружбы и любви до гроба. Тут скорее я хотел дать понять, что разработчик может управлять тем, как относятся к нему другие. "Может управлять" ключевое. А то многие же пишут, что все начальники козлы, все менеджеры только "эффективные", с такой обречённостью.
kitchip
20.11.2024 20:43Тогда вопросов особо не имею )
п4. На мой взгляд, ситуация не сильно поменялась. А кризисы были всегда, как и золотые "ковидные" года. Надо умело использовать оба механизма.
Интересно, какова будет лучшая стратегия после окончания сво...
Pardych
20.11.2024 20:43Чот и прикопаться не к чему. Внезапно адекватная статья про общение на работе.
dkfbm
20.11.2024 20:43Я бы сказал, что статья о том, как общаться с руководителем в условиях неверно организованного процесса. Например:
Ой, а я же тебе на позапрошлом дэйлике сказал, что Луна в Третьем доме, поэтому на неё забил…
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Хотя деплоит в прод за редким исключением не разработчик.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
По мере выполнения задачи могут возникать тонкости, которые знает только сам исполнитель, такие как:
— нужно не забыть добавить переменную в env;
— нужно выполнить команду на серваке и ещё запустить крон;
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
— нужно к деплою подготовить фича-ветку так, чтобы в ней были самые последние изменения из master, иначе в день деплоя по чатам будут летать сообщения на тему «Срочно исправь конфликты в своей ветке!»;
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Поднесите ему идею, заразите сомнением, дайте намёк на решение, наконец, сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас, а влияния в компании у него больше!
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Можно и ещё попридираться, но вот эти пункты просто таки глаз режут.
botyaslonim Автор
20.11.2024 20:43Отвечу так же попунктно
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Тут самый вопрос в том, кто выступает инициатором изменений. Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения". Почти одно и то же, да.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод
По-хорошему, да. Особенно когда у вас крупная компания, и никакой даже не стратап
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
В идеале да, так надёжнее. Но есть срочные хотфиксы, например.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Всё верно. Конечно, у нас есть релиз-ветки. Вопрос в том, чтобы передать информацию и важных деталях релиза конкретной фичи от разработчика (который это сконструировал) выше так, чтобы было надёжно. Иногда разработчик забывает это сделать.
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Ну тут сказать нечего. Если вам дают руку помощи, а вам кажется, что ваш труд присваивают, то просто работайте. У меня был один разработчик. Мы как-то начали пилить Nodejs-библиотеку, я, совершенно не думая, в авторах сначала указал свою фамилию, потом его. Он мне закатил хорошенькую истерику по поводу того, что я присваиваю его труд :)
Слава богу, в скорости уволился сам.dkfbm
20.11.2024 20:43Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения".
Опять-таки, вопрос организации процесса. В норме разработчик не может сам принимать решения об откладывании работ, а руководитель непрерывно мониторит изменения в тикетах, так что не может быть не в курсе, даже если такое произошло.
Особенно когда у вас крупная компания, и никакой даже не стратап
Я и писал: где в принципе присутствует иерархия руководства.
Но есть срочные хотфиксы, например.
Для хотфиксов должна быть отдельная процедура – в принципе мало чем отличающаяся, только что изменение мержится изначально не в релиз, а в хотфикс бранч, и тестируется там.
Иногда разработчик забывает это сделать.
Если забыл, то это баг, который должен был выявиться при тестировании – а отнюдь не во время попытки мержа в мастер.
Если вам дают руку помощи, а вам кажется, что ваш труд присваивают
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
botyaslonim Автор
20.11.2024 20:43...а руководитель непрерывно мониторит изменения в тикетах
И является слабым местом всей схемы. Конечно, мне приходится мониторить изменения в тикетах, но это а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач б) Неэффективно
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
Я не писал, что это необходимое условие. Но бывает, что если твоя личная идея не двигается в лоб, нужно "подарить" её руководителю, и тогда - о чудо! - она вдруг начинает двигаться быстрее.
Я когда-то думал, как вы, и тоже считал это нездоровой ситуацией. Потом со временем понял, что так тоже бывает, это часть жизни. Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали. Это разная мотивация. Я сам получаю кайф от того, что люди со временем начинают действовать так, как я бы хотел, чтобы они действовали, пусть даже совершенно не упоминая меня в качестве инициатора перемен.
dkfbm
20.11.2024 20:43И является слабым местом всей схемы.
Не понимаю. Вы предлагаете руководителю НЕ мониторить тикеты? А чем он тогда вообще занимается, и откуда узнаёт о состоянии дел?
а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач
Мне ежедневно приходит сотни полторы апдейтов. Никакой особой перегрузки это не создаёт: если держишь руку на пульсе, достаточно одного взгляда, чтобы понять – всё ли тут в порядке или требуется вмешаться. А если начинаешь не успевать – это явный индикатор того, что команду пора дробить на более мелкие.
Неэффективно
А что тогда эффективно? Поделитесь опытом.
Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
botyaslonim Автор
20.11.2024 20:43А что тогда эффективно? Поделитесь опытом
Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть. Тут выкидывается куча ненужной коммуникации, а также риски, что уведомлений о сотне задач руководитель не увидит нужное. Быстро и сразу к делу.
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
Хочется ответить репликой из "Москва слезам не верит": "Гоша! Нельзя быть таким серьёзным!"
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения. Можно просто принять, что руководитель тупой (хотя на самом деле может быть n причин что-то тормозить, о которых разработчик просто не догадывается) :)
Вопрос человеческого взаимодействия. Если разработчик сам убеждён, что идея отличная, иногда он считает, что это должно быть абсолютно очевидно и другим. А если это не так, почему-то обижается.dkfbm
20.11.2024 20:43Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть.
В этом случае описанная в статье ситуация невозможна
Всё равно эти предложения и решение руководителя должны быть отражены в тикете – что опять же делает описанную ситуацию невозможной.
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения.
Ага, а если предложить ему приписать нововведение себе, то сразу проникнется его ценностью. Камон.
botyaslonim Автор
20.11.2024 20:43предложить ему приписать нововведение себе
Это ваша постановка видения ситуации, вы так интерпретируете. Я написал по-другому. Это перечислено в числе прочих заходов, и как последний вариант. У меня нигде не написано, что руководитель шантажирует продвижением вашей идеи за мелкий прайс.
dkfbm
20.11.2024 20:43Я написал по-другому
Простите, это я никак по-другому интерпретировать не могу:
сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас
botyaslonim Автор
20.11.2024 20:43Ну да, "чтобы он подумал, что" - это не про явные договорённости "ты мне, я тебе", а скорее про симбиоз.
Программисту нужно до зарезу перейти с Vue2 на Vue3, а у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было". Вопрос в аргументации
dkfbm
20.11.2024 20:43у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было".
Так и не понял, что изменится в лучшую сторону для менеджера, если его начальство будет думать, что переход был его идеей. Скорее наоборот – для начальства верхнего уровня это ещё более "осталось, как было, а время и ресурс потратили". Он мазохист, хочет, чтобы наказали его, а не программиста?
SchwertPG
20.11.2024 20:43как там было в 17 мгновениях весны? никто не мог заподозрить Шеленберга в примитивном плагиате, потому что он подвал идею совершенно под другим соусом?)))
Homyakin
20.11.2024 20:43Как-то всё очень категорично
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Есть много подходов. В Tunk Based Development есть только мастер, очень удобная методология кстати.
dkfbm
20.11.2024 20:43Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
CI != CD. И вообще CI должна запускаться безо всякой кнопки, просто по факту мержа фичи в общий бранч.
UPD: а релиз по инициативе разработчика – это никакой не стандарт, а воплощённый кошмар. Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
В Tunk Based Development есть только мастер, очень удобная методология кстати
Есть свои плюсы, одно время использовали. Но в этом случае и деплой делается иначе. В любом случае, если программист, закончив фичу, вмерживает её в мастер и она тут же появляется на проде, без предварительного тестирования – это категорически неправильно.
kitchip
20.11.2024 20:43UPD: а релиз по инициативе разработчика – это никакой не стандарт, а воплощённый кошмар. Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
magnit, avito, ozon? Там релиз под одной кнопке, как и откат
dkfbm
20.11.2024 20:43magnit, avito, ozon? Там релиз под одной кнопке, как и откат
Ага, и каждый программист сам решает, что и когда релизить. Не верю ©
Homyakin
20.11.2024 20:43Я буквально так работаю уже много лет.
botyaslonim Автор
20.11.2024 20:43Серьёзно? В прод релизит сам разработчик? Расскажите подробнее? Это раскатка сначала на маленькой аудитории? Как тестирование строится? Кто за факапы отвечает?
kitchip
20.11.2024 20:43Да, так работаю всю жизнь =) Большая часть продуктовых команд, в которых я работал, или которые находились вокруг меня, так живёт. Fail fast подход
Да
Приходит фича, есть фича флаг(или нет). Её постепенно напиливают подливая код в мастер и деплоят на прод. Когда фича готова, её раскатывают через АБ или не через АБ
Когда как
unit, интеграционное тестирование. Тестирование на моканных данных на деве, тестирование на продовых данных, тестирование на проде. В зависимости от ситуации этапы скипаются. Часто достаточно юнит+руками тыкнуть на локале.
Фича лид(Обычно, либо разраб, либо лид команды). На моей памяти, прямо критичных инцидентов не было.
Homyakin
20.11.2024 20:43В целом, выше написали, история похожая. Разработчик делает фичу, пишет на неё тесты, если необходимо закрывает фича флагом. Далее мерж в мастер, прогонка e2e тестов, по необходимости ручное тестирование. После релиза, мониторинг ситуации на проде, по необходимости доп. тест на проде, иногда сразу на всех раскатываем иногда на часть. За факапы у нас отвечает команда, которая пилит фичу.
botyaslonim Автор
20.11.2024 20:43Вот смущает порядок "мердж в master, далее тесты". А если тесты упали? Revert-commit, reset --hard?
Homyakin
20.11.2024 20:43Как правило стараемся закрывать функциональность фича флагами, чтобы не тормозить другие команды. Но если что-то падает есть два варианта. Первый - реверт коммита. Второй, если никому сейчас сервис не нужен и можно быстро пофиксить, то сразу фиксим.
dkfbm
20.11.2024 20:43Я буквально так работаю уже много лет
Это может быть возможно в отдельно взятых проектах локального значения – но никак не отраслевой стандарт. У меня, например, пользовательская база 30М+, и убытки в случае, если некий программист выкатит кривой релиз, могут быть весьма значительными. Кто за это будет отвечать?
Вариант "тут же откатим" далеко не всегда работает: ошибка может влиять, например на ограниченное подмножество юзеров и быть замеченной не сразу, а только после того, как ещё пяток программистов накатит поверх свои изменения. Все тогда откатывать? А у юзеров фичи будут то появляться, то пропадать?
kitchip
20.11.2024 20:43Ну, не верьте(c)
Говорю за себя + своих коллег, все так работают. За это нам и платят деньги, мы берём на себя ответственность за код и фичи ¯_(ツ)_/¯
denim
20.11.2024 20:43Ваши слова да богу в уши, тот случай если надо объяснять то объяснять уже не надо, за исключением случая когда субъект это зеленый джун.
Работайте над собой друзья. Никому не нужны «сеньоры» не способные нормально донести что они делают и зачем. Приходить с проблемами (это хорошо если проактивно пришел, уже плюс!!!) и не предлагать способов решения опять же позволительно джунам, для профессионала это зашквар. Учитесь манажить «вверх», и результаты вас удивят
anonymous
НЛО прилетело и опубликовало эту надпись здесь