Comments 58
Только ЛЛМ, считающая среднее по больнице от текстов разных авторов, могла в наборе взаимоисключающих параграфов соединить ясные цели со свободой в выборе решений.
Т.е. по вашему, цель и решения, приводящие к цели, - это одно и то же? Я не понял суть вашего наезда
Решения вышестоящего уровня являются целями для нижестоящего.
Людям, любящим свободу решений, обычно нафиг не упали ясные цели.
Ничего не понял. Цель - реализовать то-то и то-то, на выходе должны закрыть такие-то потребности с такими-то метриками (доступности, надежности, whatever). Выбор решения за (командой)/разработчиком. >> Задачи ставятся "что сделать" без "как сделать", по моему все справедливо изложено.
Как правило, люди, стремящиеся получить конкретные цели с определёнными метриками, и под свободой решений понимают только то, чтобы им не мешали использовать привычные им предопределённые инструменты.
Я вот лично далеко послал бы человека, который попытался бы меня осчастливить целью более конкретной, чем "произвести что-то, что можно выгодно продать в имеющейся ситуации". Постановка и уточнение цели – это вообще самая интересная часть творческой работы.
Ну так да, от уровня зависит. Программист может повлиять на один уровень выше, но всё равно не будет делать полную проработку бизнес требований и согласований. А уж если речь про два уровня выше - там совсем труба
В небольших стартапах а ля 2 pizza team да, все влияют на всё, я согласен. Это нормально и хорошо
Про стартапы не могу уверенно прокомментировать, я всю жизнь работал в корпоративной культуре. Мне кажется, для стартапов определённость текущих целей должна быть важнее, так как они работают только в тактическом масштабе и сосредоточены на поддержании штанов прямо сейчас, в то время как корпорация живёт в первую очередь внутренней жизнью.
Это стратегия, основная цель, кстати, скорее всего - прибыль компании.
Это тактика, то как достигается цель - выбор решений.
Возможно имелось ввиду это, вроде всё логично.
Это ровно то, что корпорации делают наоборот - в не зависимости от того что заявляют компании им выгоднее делать наоьорот и они это и делают:
Значимость - чел для корпорации это шурупик и его легко заменить значит он должен боятся увольнения и держаться за свое место
Предсказуемость, Справедливость и тд - та же история
Младшему менеджементу нужно доказывать собсвенную значимость. Вот и появляются скрумы, созвоны по два раза в день, и отчеты о каждом отдельном выполненном пункте плана. Симуляция активности. Чтобы их самих, упаси боже, под зад ногой, не выпнули. Следствие токсичной корпоративной культуры, крысинных бегов и пр.
А как быть с Legacy проектами?
Там практически никакой свободы в плане архитектурных решений.
Приходится плыть по старым рельсам попутно пристраивая кирпичики .
С годами пришло понимание, что справедливо утверждение - если платят хорошие деньги, значит уважают тебя. Ко всяким там неконструктивным движениям и внутриколлективным коммуникациям вырабатываем хладнокровный подход - не принимаем все близко к сердцу ( хотя это тяжело , все таки живые люди, а не роботы)
Как сделать программиста счастливее
Это всё "как должно быть" или вы это реально применяли или работали там где это применяют? Я тоже видел всякое и как-то раз даже пытался, в приличной форме конечно же, об этом сообщить - посоветовали думать более позитивно!) Всё сильно проще, без этих ваших шарфов) /s
Я как-то офигенно так работал при очень плохо организованном, вообще неправильном и некошерном подходе к разработке. Это был завод, тебе просто выдавали ТЗ, в котором просто по большему счету описывалось что надо бизнесу, и давались контакты людей, к которым обращаться если что-то непонятно, плюс срок на работы, причем срок большой, это не микрозадачи типа спринтов, а что-то на пол года - год. И ты садился и просто писал код, большинство технических решений принимал сам. И это просто счастье было, никакого микроменеджмента, никакого ежедневного контроля за каждым вздохом, никаких бессмысленных нытингов, созвонов и прочего менеджерского булшита, и при этом в принципе вполне нормальная з/п. Реально было ощущение что ты инженер, а не какой-то тупой биоробот крутящий гайки всю смену под бдительным присмотром надзирателя.
Ну как бы да, с такими процессами и на луну летали, и самолеты делали, а эти аджайлы только тревожность повышают.
Менеджерам такое не нравится, потому что это подразумевает доверие и опору на профессионализм, им комфортнее заниматься микроменеджментом, потому что так у них возникает иллюзия контроля ситуации, и того что дело активно продвигается.
Делать-то они делали, а вот как часто у них получалось это сделать, насколько эффективно, в рамках ли сроков и бюджета -- вопрос большой. Что касается космических программ и самолётов -- посмотрите сколько там неудачных запусков, закрытых проектов, ошибок, провалов и т.д.
В книге "Scrum. Революционный метод управления проектами" Сазерленд как раз приводит в пример провальный проект ФБР/ЦРУ/кого-то_там, когда они работали по waterfall и за несколько лет не смогли поставить нужное ПО.
Сложно судить по небольшой истории @vvbob, но хочется верить, что в его случае всё закончилось хорошо, бюджет и сроки не были превышены, а пользователи действительно пользовались ПО. Но такое бывает не всегда: вполне возможно, что разработчик через год принесёт вам сервис, который в таком виде никому не нужен. В этом случае и уровень тревожности, и уровень разочарованности у всех будет выше, чем уровень раздражения во время ежедневного stand-up.
А, ну и создатели Agile сплошь программисты и инженеры
Сложно судить по небольшой истории @vvbob, но хочется верить, что в его случае всё закончилось хорошо, бюджет и сроки не были превышены, а пользователи действительно пользовались ПО. Но такое бывает не всегда: вполне возможно, что разработчик через год принесёт вам сервис, который в таком виде никому не нужен.
Разработка вовсе не в вакууме велась и не в режиме подводной лодки, все часто обсуждалось и промежуточные варианты заказчику показывались, не настолько уж мы там все были глупые. И результаты вполне использовались и развивались далее. В этом смысле было что-то вполне в духе Аджайла, но без всех этих жестких ритуалов и постоянной череды бессмысленных дедлайнов и пустых совещаний-митингов.
Я не говорил, что вы глупые или waterfall плохая методология. Просто Agile более гибкий и подходит для отрасли по типу IT. "Водопад" хорош для проектов в физическом мире, например, строительстве, где есть сильная зависимость между частями "продукта": без рва нельзя залить фундамент, без фундамента нельзя поставить стены, без стен нельзя поставить крышу, ну и т.д.
А вот это:
без всех этих жестких ритуалов и постоянной череды бессмысленных дедлайнов и пустых совещаний-митингов
уже проблема имплементации Agile-методологии. Или вашей интерпретации (например, якобы бессмысленные дедлайны могут иметь смысл, просто о этих причинах известно менеджменту, а не разработчику; но здесь, конечно, проблема менеджера, что он не смог донести смысл ограниченных сроков).
Я просто видел массу реализаций этого самого Аджайла в реальном мире, а не в рассказах проповедников, и чаще всего это именно тупая потогонка с бессмысленными дедлайнами, и дикими издержками на бестолковые совещания-отчеты перед "нащальнигами".
В проповедях Аджайла много говорят всякого благостного, о том как продуктивно и комфортно работается при такой организации, а в реальности это просто превращается в микроменеджерский ад, где недоверяющие подчиненным начальники требуют ежедневного отчета по твоим действиям и постоянно задрачивают команду глупыми авралами на пустом месте.
Видимо потому и так популярна стала тема о выгорании, как тут не выгоришь если тебе приходится иметь дело с довольно токсичной средой, и при этом работать с довольно большой неопределенностью, редко в каких случаях ты прямо уверен на 100% в сроках, но от тебя требуют их четко придерживаться. На больших временных диапазонах ошибка с прогнозом сроков выполнения разных микроподзадач взаимно компенсируется где-то ошибся в плюс, где-то в минус. Но когда идет вся эта фигня с двухнедельными спринтами, ошибка приводит к срыву спринта, разборкам и поиску виноватого. Этого никому не хочется, из-за чего начинается вся эта нервотрепка с переработками и срезанием углов в коде, лишь бы успеть к дедлайну. С другой стороны - если справился быстрее, все равно будешь ждать окончания спринта, нафига загружать себя еще больше? Вот и получается работа в рваном ритме, с постоянным стрессом и ощущением работы из-под палки. Спасибо, изобретателям Аджайла, хорошую свинью подложили коллегам!
Не, ну мне жаль, что вам приходилось работать с такими вариантами Agile.
Я, честно говоря, тоже не видел идеальной реализации Scrum, но, как говорится, "на бумаге" всё хорошо и красиво)
Просто то, о чём вы говорите, является скорее не системной/онтологической проблемой Scrum, а в целом культуры управления организации. Scrum предполагает очень большой уровень свободы команды, но мало кто решается дать такую свободу команде, и если в самом верху нет культуры Agile, то и все имплементации будут хромать и тянуть за собой проблемы, описанные вами.
Смотрите: проблемы, описанные вами, характерны не только для Scrum. Попробуем заменить в ваших словах Agile на waterfall/p3.express/extreme programming/PRINCE. Продолжает звучать так же убедительно. То есть проблема здесь именно в управленческой культуре, а не в конкретной методологии.
У Скрама одна большая проблема - это слишком жесткий фреймворк. Т.е. чтобы это называлось скрамом, нужно чтобы было планирование на спринт, демо, ретро и т.д. Даже если команде нахер всё это не нужно, если задачи проще разбить по-другому (а не по спринтам), а демо показывать никому не нужно, всё равно, блин, найдется начальник который всех будет нагибать и требовать, чтобы было именно с разбивкой по спринтам, к концу спринта всех подгонять палкой, потом устроит никому не нужное демо, а на ретро тоже обычно цирк еще тот.
Особенно, конечно, смешны сторипоинты. Это какая-то эфемерная величина, которую никто толком не понимает. Это не время, но при этом сторипоинты надо упаковать в две недели. Я уж молчу о том, что сроки обычно предсказываются от балды, потому что никому они не известны никогда. А потом еще кто-то особо умный построит график сторипоинтов и будет сравнивать эффективность команд на основании этой абсолютно высосанной из пальца метрики.
Я считаю, что Скрам не нужен вообще. Лучше просто перестраивать процессы под свои нужды, используя разные инструменты, исходя из реальности и потребностей. Канбан в этом смысле намного лучше - это просто набор инструментов, он ничего не навязывает.
Что значит "слишком жёсткий"? 3 роли, 5 ритуалов, 3 артефакта. Способ реализации команда выбирает сама. Выглядит достаточно просто и гибко.
Надо смотреть, почему вам не нужны спринты, демо и ретро. Возможно, они просто в проекте реализованы криво. Но если нет, то как бы не беда: есть другие методологии, и если они лучше подходят под специфику вашего проекта, то конечно же лучше переходить на них (а ещё лучше начинать в них).
Насчёт сторипоинтов согласен. По опыту либо стори-поинты "внутри себя" уже содержат временное измерение, либо оценка по времени указывается дополнительно отдельным полем. В целом прикольно, что они указывают на сложность/неопределённость задачи, но capacity всё равно меряют в часах/рабочих_днях.
Лучше просто перестраивать процессы под свои нужды, используя разные инструменты, исходя из реальности и потребностей
Наверняка есть такие проекты, где нужен прямо кастом-кастом, но...Не для большинства же. Вам всё равно придётся в том или ином виде внедрять события, которые уже реализованы во многих методологиях: планирование, совещания/синхронизация, рефлексия, демонстрация/отчёты. Почему бы не взять готовое? Не обязательно Scrum.
насчет спринтов и демо. Моя команда больше половины времени занималась поддержкой уже созданных микросервисов. Никому наше демо было не нужно (заказчики изменений были в курсе всего или вообще даже тестировали их вместе с нами), да и показать это на демо было не просто. Типа добавили в апи какую-то очередную хрень, а в кафку плюём другую очередную хрень.
Спринты были не нужны, потому что иногда задачи по размеру не подходили: например, одна важная задача влезает, а две - уже нет. И стоял выбор: либо вместо второй важной набить спринт какой-то хренью или же оформить перенос недоделанной задачи между спринтами или делать искусственное разделение задачи. Зачем этот гемор?
Всё это ради совершенно искусственно высосанной из пальца концепции скрама. Не нужны нам были ни роли , ни ритуалы, у нас и без скрама всё было норм, клянусь. Я был тимлидом маленькой сработанной команды, всё происходящее видел и контролировал, команда работала хорошо. ПРосто сверху назначили скрам. Стало чуть хуже.
На ритуалы эти ваши уходил целый день суммарно. Это просто бред. планирование+ демо+ретро+груминг
Способ реализации команда выбирает сама
но не в этой реальности
Просто Agile более гибкий и подходит для отрасли по типу IT.
Тут тоже есть о чем поговорить. Возможно он стал лучше подходить из-за того что его так полюбили менеджеры.
Это такой эффект зрительного зала. Допустим в зале все сидят на своих местах ,всем видно сцену, все хорошо. Но тут несколько зрителей в передних местах встают и начинают смотреть стоя. Тем кто сидит за ними уже плохо видно, они вынуждены тоже встать. За ними зрители уже ничего не видят и тоже встают.. В итоге все люди зачем-то мучаются и стоят на ногах все представление, хотя и могли бы спокойно сидеть.
Так и здесь, некоторое количество менеджеров полюбило весь этот Аджайл за возможность устроить этим самым своенравным программистам рабочий концлагерь. Они начали выпускать софт по принципу - пофигу качество, главное быстро и щемить рынок вокруг своими сляпанными на скорую руку поделками, конкурентам не осталось ничего лучше, чем следовать этому примеру, иначе просто разоришься, пока пытаешься выдать качественный софт. В итоге у нас теперь все софтопроизводство "смотрит представление стоя на ногах", а то еще и "подпрыгивает", хотя могло бы работать спокойно и выдавать качественный продукт вместо наспех сколоченного нечто, абы побыстрее.
хорош для проектов в физическом мире
Декларативно аджайл не отказывается взаимодействовать с "физическим миром", но вот так...
.
Я сейчас как раз работаю над рекомендациями по совладанию со стрессом на работе именно для ИТ-специалистов и, очень жалею, что не видела эту модель раньше – многое пришлось «изобретать» с нуля. В свою защиту скажу, что научно обоснованных рекомендаций, адаптированных именно под ИТ и российские реалии, пока не так много.
Я работаю с айтишниками как психолог, и, разумеется, те, у кого всё благополучно, редко становятся клиентами. С пунктами модели, представленной в статье, по своему практическому опыту согласна на все 100.
Фактор непредсказуемости действительно часто связан с ростом тревоги. Понятно, что в работе программиста полностью устранить неопределённость невозможно: даже код, который вчера работал стабильно, сегодня может всё поломать. Однако, по моим наблюдениям, ситуация воспринимается значительно спокойнее, когда сроки и требования хотя бы относительно предсказуемы, а решения сопровождаются объяснением логики, а не только формулировкой «так решили».
Отдельная тема - автономия. Многие инженеры приходят в профессию именно потому, что им важно самостоятельно принимать технические решения. В ряде случаев я наблюдала, что избыточное количество созвонов и постоянный контроль скорее повышают напряжение, чем ускоряют работу, особенно если они не добавляют ясности по задачам.
Также часто всплывает вопрос справедливости: переработки, работа в выходные или во время отпуска в формате «посмотри, там чуть-чуть» нередко воспринимаются как норма, но не всегда компенсируются финансово или дополнительным отдыхом. Это, по понятным причинам, влияет на отношение к работе и уровень стресса.
И когда сложно работать автономно, сам процесс работы повышает неопределённость, а не снижает её, и приходится жертвовать своим отдыхом, у человека легко формируется ощущение «я ничего не успеваю», и появляются сомнения в себе как в специалисте.
В этом смысле статья кажется мне хорошей основой для обсуждения условий, которые действительно помогают программистам работать устойчиво и без лишнего напряжения. И, конечно, сами разработчики вряд ли смогут напрямую «внедрить» такую модель в организации, но если хотя бы знать, «как комфортнее», то можно к этому стремиться самому. Ну и невзначай подсунуть описание этой модели руководству))
Я работаю с айтишниками как психолог, и, разумеется, те, у кого всё благополучно, редко становятся клиентами.
Очень мудрое замечание. А если сделать всё под тревожных людей, которые становятся клиентами производственного психолога, то не тревожные люди могут ведь и разбежаться за отсутствием поля для самореализации.
И куда же Вы убежали от "аппаратно-программных комплексов"? :-)
Не понял вопроса.
Но был в жизни как-то случай, когда окружение наводнили люди, полагающие необходимым мне объяснять, в чём состоит цель моей работы. В конце концов пришлось поменять организацию, а работа осталась той же, так как жизнь устроена таким образом, что был бы маузер, а цель для него найдётся.
Вы написали свой комментарий после слов психолога:
Отдельная тема - автономия. Многие инженеры приходят в профессию именно потому, что им важно самостоятельно принимать технические решения. В ряде случаев я наблюдала, что избыточное количество созвонов и постоянный контроль скорее повышают напряжение, чем ускоряют работу, особенно если они не добавляют ясности по задачам.
И мне показалось, что Вы нашли для себя достаточно "автономную" работу, чтобы особенно не бегать.
Если программист будет весело решать проблемы в дружеской атмосфере, то он будет творить чудеса. Если его так или иначе "щемить" и микроменеджить, то чудеса придется творить менеджеру, чтобы хоть что-то куда-то ехало.
Только вот жестокая реальность состоит в том, что бизнесу все эти чудеса не нужны, ему нужен работающий конвейер, с типовыми, легкозаменяемыми рабочими юнитами. Если биоробот начал сбоить и плохо работать, можно для начала отправить его на ТО (отпуск), если это не помогает, то его надо просто выбросить и купить вместо него нового. А креативность вся эта, она слишком непредсказуема и и только мешает работать конвейеру.
Не всегда, бизнес бизнесу рознь. Даже разные направления внутри того же бизнеса.
Не всегда, но чаще все-же нужен именно конвейер.
Конвейер не обязательно потогонная система.
Чаще... Интересно, это кто-то считал, бывает это чаще или реже?
На моем личном опыте, конвейер нужен только для самых простых задач, в которых человека легко заменить ИИ. А для абсолютного большинства задач либо нужны люди, которые умеют мыслить out of the box, либо конвейер уезжает куда-то не туда, куда нужно. Но один я, конечно, слишком маленькая выборка :-)
Статья хороша - структурированное описание того, что многие чувствуют интуитивно, но редко формализуют. SCARF довольно точно ложится на боли программистов: от toxic code review до хаотичных приоритетов и микроменеджмента
Особенно откликнулся момент про предсказуемость и автономию - даже сложные и неприятные задачи воспринимаются спокойнее, когда понятно "зачем" и есть свобода в реализации
Еще зашло про relatedness: культура обсуждений и отношение к ошибкам сильно влияют на качество решений
В целом чеклист хорош для тимлидов и менеджеров: если хотя бы часть пунктов соблюдается в команде, она начинает работать заметно эффективнее
Видимо, для большинства организаций расшифровки будут несколько другие:
Silent agreement
Conformity
Agism of hiring
Running of loyality
Favoritism
Как сделать программиста счастливее
Не мешать ему работу работать?
В точку про "окукливание". Как совладелец ИТ-бизнеса, я часто видела, как крутой инженер превращается в пассивного исполнителя за пару месяцев микроменеджмента. У меня вопрос по пункту Fairness (справедливость): часто бывает, что правила прозрачные, но фоновая тревога у команды всё равно растёт. Как вы считаете, может ли "прозрачность" сама по себе стать токсичной, если за ней нет реального доверия, а только сухие цифры и отчеты?
Возможно, стоит поговорить с людьми, что именно они считают несправедливым. Сложно сказать издалека
А точно ли в прозрачности/честности дело? Может быть, что у сотрудника всё в порядке с доверием, но беспокоят другие вещи. Сложность проекта, поведение заказчика, состояние рынка...
Согласна, внешнего треша всегда хватает: то заказчик «горит», то рынок падает. Но фокус в том, что на эти вещи мы напрямую не влияем.
Прозрачность нужна не для того, чтобы рынок успокоить, а чтобы руководитель перестал в одиночку тащить ответственность за всё подряд. Выгорание ведь часто случается там, где мы пытаемся создать для команды иллюзию, что «всё под контролем», хотя проект объективно сложный. В итоге все друг другу доверяют, но руководитель медленно умирает под грузом этой недосказанности. Прозрачность — это просто способ честно разделить реальность с командой, чтобы не сгореть самому
В целом статья довольно неплохая, но вот некоторые моменты или в жизни почти никогда не работают или работают очень плохо.
Свобода в выборе технических решений
Вот это утверждение очень спорное - разраб, сам того не ведая, может очень сильно поднасрать компании в ближайшем или отдалённом будущем если применит какой-нить крайне неподходящее решение, которое потом или переделывать или мучатся с ним годами.
Я согласен. Если кто-то напишет микросервис на языке BrainFuck, то потом будет тяжело. Но это крайний случай. Я говорю про другое, когда пытаются делать из людей дешевые винтики, или просто у директораа есть какой-то бзик. Типа, пишем только на такой-то версии, используем только библиотеки из списка и т.д. И тогда мы Васю за один день заменим на Петю из соседнего отдела. Но у этого подхода есть психологическая цена.
Например, я слышал, что в Skyeng всё писали на php, потому что так решил их тех дир. При этом писали статьи, как они ловко выкручиваются и наворачивают на пхп сложные системы, чтобы выжить. Вместо того, чтобы добавить немного Go в многопоточных местах. Я точно не знаю, но предполагаю, что команда с этого знатно выгорала.
Я сталкивался с подобными ситуациями, когда навязывался фреймворк или, наоборот, писать вообще без фреймворка. Хотя вся команда не понимала, почему, и погдорала с этого.
Я пришел к выводу, что надо давать максимум свободы, если нет прям явных противопоказаний. Понятно, что зависит от конкретной ситуации
Как сделать программиста счастливее