Comments 53
звучит банально, но для новеньких будет полезно
Чтобы исполнители были более ответственные труд должен быть организован так чтобы он способствовал появлению этой ответственности.
Руководство часто забывает, что оно работает с людьми, а не роботами и пытается превратить все в самоходную систему. Чтобы уменьшить bus-фактор и облегчить себе распределение работы руководство часто обезличивает исполнителей, лишая их специализации на одном элементе системы. Принцип - все должны работать над всем. Если завтра Вася свалит в закат, то Петя сможет делать его работу, поэтому Петя должен каждый божий день мониторить и мириться с тем что наделал Вася. Петя универсальный солдат. Очень удобно для менеджера. Показываешь команде таких универсалов кучу работы и говоришь "Фас! Сделайте мне красиво!" Они там сами разберутся. Не надо париться с тем чтобы искать работу исполнителю потому что всегда какая то работа есть и не надо париться с тем чтобы искать исполнителя на эту работу.
Я как исполнитель могу сказать что я был бы более ответственным если бы мне дали мотыжить свой участок. Когда над одним участком кода работает много людей, то очень трудоёмко становится ежедневно удерживать понимание того как это все работает. Не секрет, что читать код сложнее, чем писать. Каждый раз как в первый раз приходится заново исследовать, а как же теперь работает этот чёрный ящик. Такое глубокое исследование должно делаться один раз в начале работы, а потом каждый день человек маленькими усилиями развивает модуль. А если приходится постоянно заниматься такой деятельностью то это способствует выгоранию. И вообще это какой-то абсурд, когда команде как коллективному целому постоянно приходится реально изучать, разбираться с тем, что эта же команда наделала. Т.е. мы не понимаем, что мы делаем?! Ладно там если люди увольняются, то надо разобраться с их наследием, но почему я должен каждый день до ночи вникать в детали их реализаций?! Я взрослый человек и кроме работы у меня еще другие могут быть интересы в жизни.
К тому же другие люди часто расширяют код нет так как это бы сделал я, с чувством, с толком, с расстановкой. Особенно раздражают гастролеры, которым лишь бы воткнуть куда-то что-то не в тему и не в систему лишь бы быстренько закрыть свою задачу и побежать дальше с высоким KPI, а мне потом возиться с этим.
Другой момент это то, что программировать это не всегда типовая работа. У человека который печёт пирожки все понятно, только делай. В программировании же часто приходится решать задачи в которых надо придумать решение. Я реально не могу дать оценку сколько времени на это уйдёт: день, неделя, месяц или вся жизнь.
Есть же простое решение: открыть свою фирму и писать свой код. Тогда вам никто не будет говорить, что надо делать.
Либо это звучит как "кладите мою зарплату в тумбочку и отвалите, я занимаюсь тем, что мне нравится".
Я бы сказал, звучит не банально. Но в перемешку вредные и полезные советы :)
А какие вредные?
Пункт 4. Инициативность. Быть инициативным себе дороже. Рост зп не соответствует росту прилагаемых усилий, проверено не единожды. Повышение денег на уровень инфляции - не является повышением ;)
А вот джопхопинг до какого-то момента является лучшим способом расти на 30-40% в год. Примерно до 550к нет в месяц(на данный момент), затем уже можно начать задумываться о: смещение фокуса в другие области, каминг-аут в менеджеры/лиды, валютные удаленки. Но во всех вариантах надо очень аккуратно считать профит и потери
Пункт 5. Доверие. Какой-то процент его должен быть, но не 100%. Всё-таки цели линейного работника и его начальника, обычно, различаются.
С остальным полностью согласен.
Про п.4 я сразу предполагал, что его поймут не только лишь все :)
Да, джобхоппинг в среднем был проще до недавнего времени. Но бывают случаи, когда и компания хочет разработчику что-то интересное дать, и разработчик хочет больше денег и статуса, а у них ничего не получается из-за сущей ерунды - они просто не начинают говорить об этом. И в последнее время, кмк, это станет актуальнее в связи с кризисом в экономике и тем, что программистов, кажется, на рынке труда становится больше, а вакансий меньше.
П.5 да, полного доверия не будет, как и дружбы и любви до гроба. Тут скорее я хотел дать понять, что разработчик может управлять тем, как относятся к нему другие. "Может управлять" ключевое. А то многие же пишут, что все начальники козлы, все менеджеры только "эффективные", с такой обречённостью.
Тогда вопросов особо не имею )
п4. На мой взгляд, ситуация не сильно поменялась. А кризисы были всегда, как и золотые "ковидные" года. Надо умело использовать оба механизма.
Интересно, какова будет лучшая стратегия после окончания сво...
Если солдат не ругается на генерала, то это значит, что что-то идет не так
Чот и прикопаться не к чему. Внезапно адекватная статья про общение на работе.
Я бы сказал, что статья о том, как общаться с руководителем в условиях неверно организованного процесса. Например:
Ой, а я же тебе на позапрошлом дэйлике сказал, что Луна в Третьем доме, поэтому на неё забил…
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Хотя деплоит в прод за редким исключением не разработчик.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
По мере выполнения задачи могут возникать тонкости, которые знает только сам исполнитель, такие как:
— нужно не забыть добавить переменную в env;
— нужно выполнить команду на серваке и ещё запустить крон;
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
— нужно к деплою подготовить фича-ветку так, чтобы в ней были самые последние изменения из master, иначе в день деплоя по чатам будут летать сообщения на тему «Срочно исправь конфликты в своей ветке!»;
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Поднесите ему идею, заразите сомнением, дайте намёк на решение, наконец, сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас, а влияния в компании у него больше!
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Можно и ещё попридираться, но вот эти пункты просто таки глаз режут.
Отвечу так же попунктно
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Тут самый вопрос в том, кто выступает инициатором изменений. Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения". Почти одно и то же, да.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод
По-хорошему, да. Особенно когда у вас крупная компания, и никакой даже не стратап
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
В идеале да, так надёжнее. Но есть срочные хотфиксы, например.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Всё верно. Конечно, у нас есть релиз-ветки. Вопрос в том, чтобы передать информацию и важных деталях релиза конкретной фичи от разработчика (который это сконструировал) выше так, чтобы было надёжно. Иногда разработчик забывает это сделать.
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Ну тут сказать нечего. Если вам дают руку помощи, а вам кажется, что ваш труд присваивают, то просто работайте. У меня был один разработчик. Мы как-то начали пилить Nodejs-библиотеку, я, совершенно не думая, в авторах сначала указал свою фамилию, потом его. Он мне закатил хорошенькую истерику по поводу того, что я присваиваю его труд :)
Слава богу, в скорости уволился сам.
Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения".
Опять-таки, вопрос организации процесса. В норме разработчик не может сам принимать решения об откладывании работ, а руководитель непрерывно мониторит изменения в тикетах, так что не может быть не в курсе, даже если такое произошло.
Особенно когда у вас крупная компания, и никакой даже не стратап
Я и писал: где в принципе присутствует иерархия руководства.
Но есть срочные хотфиксы, например.
Для хотфиксов должна быть отдельная процедура – в принципе мало чем отличающаяся, только что изменение мержится изначально не в релиз, а в хотфикс бранч, и тестируется там.
Иногда разработчик забывает это сделать.
Если забыл, то это баг, который должен был выявиться при тестировании – а отнюдь не во время попытки мержа в мастер.
Если вам дают руку помощи, а вам кажется, что ваш труд присваивают
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
...а руководитель непрерывно мониторит изменения в тикетах
И является слабым местом всей схемы. Конечно, мне приходится мониторить изменения в тикетах, но это а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач б) Неэффективно
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
Я не писал, что это необходимое условие. Но бывает, что если твоя личная идея не двигается в лоб, нужно "подарить" её руководителю, и тогда - о чудо! - она вдруг начинает двигаться быстрее.
Я когда-то думал, как вы, и тоже считал это нездоровой ситуацией. Потом со временем понял, что так тоже бывает, это часть жизни. Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали. Это разная мотивация. Я сам получаю кайф от того, что люди со временем начинают действовать так, как я бы хотел, чтобы они действовали, пусть даже совершенно не упоминая меня в качестве инициатора перемен.
И является слабым местом всей схемы.
Не понимаю. Вы предлагаете руководителю НЕ мониторить тикеты? А чем он тогда вообще занимается, и откуда узнаёт о состоянии дел?
а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач
Мне ежедневно приходит сотни полторы апдейтов. Никакой особой перегрузки это не создаёт: если держишь руку на пульсе, достаточно одного взгляда, чтобы понять – всё ли тут в порядке или требуется вмешаться. А если начинаешь не успевать – это явный индикатор того, что команду пора дробить на более мелкие.
Неэффективно
А что тогда эффективно? Поделитесь опытом.
Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
А что тогда эффективно? Поделитесь опытом
Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть. Тут выкидывается куча ненужной коммуникации, а также риски, что уведомлений о сотне задач руководитель не увидит нужное. Быстро и сразу к делу.
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
Хочется ответить репликой из "Москва слезам не верит": "Гоша! Нельзя быть таким серьёзным!"
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения. Можно просто принять, что руководитель тупой (хотя на самом деле может быть n причин что-то тормозить, о которых разработчик просто не догадывается) :)
Вопрос человеческого взаимодействия. Если разработчик сам убеждён, что идея отличная, иногда он считает, что это должно быть абсолютно очевидно и другим. А если это не так, почему-то обижается.
Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть.
В этом случае описанная в статье ситуация невозможна
Всё равно эти предложения и решение руководителя должны быть отражены в тикете – что опять же делает описанную ситуацию невозможной.
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения.
Ага, а если предложить ему приписать нововведение себе, то сразу проникнется его ценностью. Камон.
предложить ему приписать нововведение себе
Это ваша постановка видения ситуации, вы так интерпретируете. Я написал по-другому. Это перечислено в числе прочих заходов, и как последний вариант. У меня нигде не написано, что руководитель шантажирует продвижением вашей идеи за мелкий прайс.
Я написал по-другому
Простите, это я никак по-другому интерпретировать не могу:
сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас
Ну да, "чтобы он подумал, что" - это не про явные договорённости "ты мне, я тебе", а скорее про симбиоз.
Программисту нужно до зарезу перейти с Vue2 на Vue3, а у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было". Вопрос в аргументации
у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было".
Так и не понял, что изменится в лучшую сторону для менеджера, если его начальство будет думать, что переход был его идеей. Скорее наоборот – для начальства верхнего уровня это ещё более "осталось, как было, а время и ресурс потратили". Он мазохист, хочет, чтобы наказали его, а не программиста?
Как-то всё очень категорично
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Есть много подходов. В Tunk Based Development есть только мастер, очень удобная методология кстати.
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
CI != CD. И вообще CI должна запускаться безо всякой кнопки, просто по факту мержа фичи в общий бранч.
UPD: а релиз по инициативе разработчика – это никакой не стандарт, а воплощённый кошмар. Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
В Tunk Based Development есть только мастер, очень удобная методология кстати
Есть свои плюсы, одно время использовали. Но в этом случае и деплой делается иначе. В любом случае, если программист, закончив фичу, вмерживает её в мастер и она тут же появляется на проде, без предварительного тестирования – это категорически неправильно.
UPD: а релиз по инициативе разработчика – это никакой не стандарт, а воплощённый кошмар. Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
magnit, avito, ozon? Там релиз под одной кнопке, как и откат
magnit, avito, ozon? Там релиз под одной кнопке, как и откат
Ага, и каждый программист сам решает, что и когда релизить. Не верю ©
Я буквально так работаю уже много лет.
Серьёзно? В прод релизит сам разработчик? Расскажите подробнее? Это раскатка сначала на маленькой аудитории? Как тестирование строится? Кто за факапы отвечает?
Да, так работаю всю жизнь =) Большая часть продуктовых команд, в которых я работал, или которые находились вокруг меня, так живёт. Fail fast подход
Да
Приходит фича, есть фича флаг(или нет). Её постепенно напиливают подливая код в мастер и деплоят на прод. Когда фича готова, её раскатывают через АБ или не через АБ
Когда как
unit, интеграционное тестирование. Тестирование на моканных данных на деве, тестирование на продовых данных, тестирование на проде. В зависимости от ситуации этапы скипаются. Часто достаточно юнит+руками тыкнуть на локале.
Фича лид(Обычно, либо разраб, либо лид команды). На моей памяти, прямо критичных инцидентов не было.
В целом, выше написали, история похожая. Разработчик делает фичу, пишет на неё тесты, если необходимо закрывает фича флагом. Далее мерж в мастер, прогонка e2e тестов, по необходимости ручное тестирование. После релиза, мониторинг ситуации на проде, по необходимости доп. тест на проде, иногда сразу на всех раскатываем иногда на часть. За факапы у нас отвечает команда, которая пилит фичу.
Я буквально так работаю уже много лет
Это может быть возможно в отдельно взятых проектах локального значения – но никак не отраслевой стандарт. У меня, например, пользовательская база 30М+, и убытки в случае, если некий программист выкатит кривой релиз, могут быть весьма значительными. Кто за это будет отвечать?
Вариант "тут же откатим" далеко не всегда работает: ошибка может влиять, например на ограниченное подмножество юзеров и быть замеченной не сразу, а только после того, как ещё пяток программистов накатит поверх свои изменения. Все тогда откатывать? А у юзеров фичи будут то появляться, то пропадать?
Все тогда откатывать? А у юзеров фичи будут то появляться, то пропадать?
Добро пожаловать в мир A/B-тестов. Как раз это - стандарт отрасли и продуктовой разработки. Когда продукт становится достаточно крупным и успешным, большинство изменений прогоняются через исследования пользовательского опыта, а также эксперименты по влиянию на аудиторию. Так что ситуация "у меня фича есть, а у соседа Васи нет" - это прям норма.
Выкатить незрелую фичу - это всё ещё проблема. Но в таких компаниях и QA процессы давольно серьёзные и основательные. Однако, выкатка фичи - это не релиз, это включение тоггла или запуск A/B-теста. Перед этим ответственным событием разработчики спокойно релизят в прод кусочки фичи - до запуска их никто не увидит.
Так что ситуация "у меня фича есть, а у соседа Васи нет" - это прям норма.
Вы бы почитали сначала, о чём речь, прежде чем постить многочисленные гневные комменты. Меня уверяли, что любой программист может мгновенно выложить фичу в продакшн по собственной инициативе, нажатием одной кнопки (== сделать её доступной конечным пользователям). Что совершенно не одно и то же с выкладыванием её под флагом доступности только для себя, любимого. Такие конфигурации есть, и достаточно популярны – сам тоже иногда применяю. Но редко, в основном у нас используется отдельный стэйджинг сервер, где и проходят финальные проверки перед релизом. И в одном, и в другом случае релиз фичи для конечных юзеров – это бизнес решение, программист его принимать не может. Тем более, каждый программист.
Нет, вас уверяли, что любой программист может релизить в прод - и это верно для крупных компаний с микросервисной архитектурой. Это не имеет ничего общего со стейджинговым окружением - оно тоже есть и это отдельная история. Код в проде, релизит разработчик, когда посчитает нужным, ответственность - на нём.
Вы меня вспомнили, поэтому сейчас пытаетесь состроить хорошую мину при плохой игре, но все могут перечитать ваши комменты и о чём вы спорили)
Вы меня вспомнили, поэтому сейчас пытаетесь состроить хорошую мину при плохой игре
Извините, Вы преувеличиваете свою значимость для меня. Не вспомнил, просто ответил на конкретный комментарий по существу. Если Вам мой ответ непонятен – ничего не могу поделать, любой может тут ознакомиться с тем, кто что кому писал. Вы тоже.
Когда хочется быть Д'Артаньяном, но историю-то не перепишешь:
Представьте себе команду из нескольких десятков, а то и сотен программистов, каждый из которых релизит в прод, когда ему вздумается.
Буквально так и происходит. Выстраиваемся в очередь в специальных чатиках. Мёрж в мастер без релиза считается дурным тоном, ибо твою фичу за тебя никто не покатит. Ничего, работаем как-то.
историю-то не перепишешь
Зачем переписывать? Именно так я и написал, и продолжаю так считать. И всякий, кто использует устоявшуюся терминологию ("релиз" есть публикация новой версии приложения для конечных пользователей) , со мной согласится. То, о чём Вы пишете, это просто никакой не релиз, а один из этапов тестирования.
Ну, не верьте(c)
Говорю за себя + своих коллег, все так работают. За это нам и платят деньги, мы берём на себя ответственность за код и фичи ¯_(ツ)_/¯
Решает не "программист", а фича лид. Который часто является разработчиком
Не верю
Вы опять со своей самоуверенностью спорите с теми, кто действительно так работает десятки лет?
Ну напраситесь в предложенные компании на собеседование и вам расскажут. Намекну, в двух словах, почему это нормально и работает: микросервисы, масштабирование, канареечные релизы.
Ваши слова да богу в уши, тот случай если надо объяснять то объяснять уже не надо, за исключением случая когда субъект это зеленый джун.
Работайте над собой друзья. Никому не нужны «сеньоры» не способные нормально донести что они делают и зачем. Приходить с проблемами (это хорошо если проактивно пришел, уже плюс!!!) и не предлагать способов решения опять же позволительно джунам, для профессионала это зашквар. Учитесь манажить «вверх», и результаты вас удивят
Как общаться с руководителем