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