Тяжесть решений: кто же на самом деле несет ответственность в IT?
Для начала представлюсь - я разработчик с более чем 15-летним стажем. За это время я работал в самых разных компаниях — от маленьких стартапов до крупных корпораций, в одиночку и в больших командах. Хочу рассказать о несправедливости в IT, с которой мне пришлось столкнуться.
Кто виноват?
Так уж сложилось, что все задачи, которые поручают разработчику, автоматически предполагают, что за любые ошибки он несет полную ответственность. Но редко кто задумывается, что в процесс вовлечено множество людей, и каждый из них влияет на конечный результат.
Пример (оценка разработчиков менеджерами).
Оценка разработчиков менеджерами она строится на воспоминаниях: этот сотрудник часто ошибается, а этот — редко. Но такая оценка поверхностна и несправедлива. Вот реальный случай:
Петр выполнил 15 задач за месяц и сделал в них 5 ошибок.
Василий — 4 задачи с 4 ошибками.
Менеджер может запомнить, что Петр часто ошибается, не обращая внимания на то, что он сделал гораздо больший объем работы. (Пропорционально ошибок у него даже меньше).
Или другой пример:
Петр выполнил 15 задач с 21 ошибкой (все исправлены).
Василий — 4 задачи с 4 ошибками.
На первый взгляд, кажется, что Петр некомпетентен. Однако он сделал больше задач, а значит, принес больше пользы компании. Логично, что с ростом объема работы вероятность ошибок увеличивается. Тогда почему менеджеры учитывают одни факторы не учитывая другие при оценке исполнителей?
А что считать ошибками?
Нередко разработчиков винят за то, что они сделали ровно то, что было описано в задаче, но этого оказалось недостаточно. Например, постановщик задачи недостаточно подробно описал требования. Кто здесь виноват? Если ошибки оцениваются только у разработчиков, то ошибки всех принимавших участие в задаче — становятся виной только одного разработчика. (а на самом деле могут быть виноваты все от рукоdjlcndf, до qa менеджера, или других разработчиков, или даже ошибка есть а не виноват никто по ряду причин).
К тому же критика менеджеров или руководства в IT воспринимается как дурной тон. Разработчик вряд ли станет доносить на постановщика задачи о его ошибках, ведь это может плохо сказаться на его репутации и привести к последующему увольнению.
Проблема двойных стандартов
Ситуация усугубляется двойными стандартами руководства.
Если разработчик делает только то, что от него просят, ему говорят, что он недостаточно инициативен. Если он предлагает улучшения или сам придумывает задачи, его упрекают в том, что он выходит за рамки. (и нужно исправлять баги после нового не нужного функционала, или там лишний раз проверять и тестировать).
Менеджеры и заказчики все чаще перекладывают свои обязанности на разработчиков:
Сам ставь себе задачи.
Сам разбирайся в бизнес-логике проекта.
Сам предлагай решения.
Мало того, разработчику приходится выполнять работу за смежные отделы. Например, писать фронтенд, заниматься дизайном UX/UI, тестированием или даже настройкой серверов.
Не менеджеры, а проблема
Часто проблемы вызваны неработающими бизнес-процессами. Например:
Плохо налажена коммуникация между командами.
Несогласованная работа нескольких разработчиков над связанным кодом приводит к конфликтам.
Руководители назначают нереалистичные сроки, игнорируя оценки сотрудников.
Разработчики боятся давать честные прогнозы, опасаясь критики. В результате сроки искусственно занижаются, что приводит к срывам.
В чём корень проблемы?
Все сводится к тому, что у кого есть власть, тот формально оказывается «прав». Ошибки руководства нельзя исправить потому что начальство не критикуют, и начальство из раза в раз может делать одни и теже ошибки, не пытаясь совершенствоваться.
Иерархическая структура в IT часто лишена справедливости. Успехи компании — заслуга руководства, а все неудачи возлагаются на исполнителей.
Задачи разработчиков сводятся не к улучшению проектов, а к угадыванию предпочтений начальства и избеганию конфронтаций.
Что делать?
Проблема требует системных изменений.
Четко фиксировать ответственность на каждом этапе работы.
Объективно оценивать результаты, учитывая объем выполненных задач.
Налаживать бизнес-процессы и обеспечивать честную коммуникацию внутри компании.
Ставить реальные сроки, опираясь на мнение тех, кто выполняет работу. (Не пытаться давить на сроки выполнения обосновывая тем что кто-то другой считает иначе, если другой разработчик считает что можно сделать в 3 раза быстрей то пусть и делает, это будет его ответственность, а назначать сроки по чужому мнению это несправедливо).
Комментарии (20)
pavelsha
05.12.2024 05:38Менеджеры и заказчики все чаще перекладывают свои обязанности на разработчиков
Попробуйте запросить перекладывание обязанностей вместе с перекладывание денег. Бывает, что это решает ситуацию. Правда иногда решает переходом в другую компанию
AlexXYZ
05.12.2024 05:38Проблема требует системных изменений.
тут уже не помочь. Если руководство само изначально не ставило целью создание обратных связей в работе, то с такой работой лучше расстаться. Дальше будет только хуже.
Есть у меня на работе один проект в котором есть маленькая фича - таблица параметров, где чётко написаны все названия (входные) по всем чихам заказчика и эти названия обязаны соблюдать и заказчики и исполнители (программисты). И таблица эта существует в двух экземплярах - у заказчика и у исполнителей. Как только заказчик что-то хочет, то сразу вопрос - что из существующих параметров использовать или добавляйте новые. Заказчик тему просёк и уже сам приносит таблицу и говорит - вот новая таблица параметров, вот расчёт на основе этих параметров (даже в Excel можно писать формулы с этими параметрами). В работу такое принимается часто в тот же день и так же быстро делается. Сроков никто специально не ставит, потому что исправления чисто статистически делаются до двух дней, а часто и раньше.
stracca
05.12.2024 05:38Оценка разработчиков менеджерами она строится на воспоминаниях
Что за странная аксиома?
Гораздо правильней будет в лоб спросить: "Как оценивается моя эффективность?"
Никто не скажет "по воспоминаниям", это сюр)
Всё это решается простыми договорённостями между сотрудником и его менеджером: Оцениваешь по количеству задач закрытых в срок? Срок откуда берётся? Из головы менеджера? Думайте сами, устраивает вас такое или нет. Если срок берётся от программиста - замечательно, то что искали.
Я к тому, что как правило такие метрики эффективности обсуждаемы в нормальных коллективах, если вы не договоритесь за себя, то кто?
sergey-gornostaev
05.12.2024 05:38По тексту очень похоже, что вы просто работаете в плохих компаниях.
DmitryR3989
05.12.2024 05:38Корень проблемы, как мне кажется, в недосказанности между всеми участниками процесса. Пока кто-то боится задать вопрос или уточнить детали, чтобы не показаться "некомпетентным", такие ситуации будут повторяться.
Многие проблемы решаются, если заранее договариваться о зонах ответственности и фиксировать ожидания: кто что делает и за что отвечает. Ну и метрики надо учитывать адекватно — смотреть не только на количество ошибок, но и на сложность задач и объем проделанной работы.
А еще очень важно нормально общаться в команде. Если есть честный диалог между менеджерами, постановщиками и разработчиками, таких ситуаций можно избежать.
IvanSTV
05.12.2024 05:38Задачи разработчиков сводятся не к улучшению проектов, а к угадыванию предпочтений начальства и избеганию конфронтаций.
вообще-то это в любой работе так. Везде работник на должности, которая подразумевает инвариантность действий, должен догадываться, что хочет начальство, ну, а конфронтации в условиях наемного труда для работника в принципе невыгодны, потому что он изначально в уязвимом положении. Желания начальства не должны угадывать только те, у которых очень узкие и рутинные обязанности, и постановка задач происходит техпроцессом без участия начальника как на конвейере.
Ну, а сам подход тут тоже так себе... Разработчика не за что винить?
SellerOfSmiles
05.12.2024 05:38Программисты виноваты всегда. Потому что некоммуникабельны.
Жизнь штука не справедливая. Потому что гладиолус.
Не нравиться работать с несправедливым начальником? Найди себе справедливого.
Все начальники несправедливы? Измени свое отношение к ним или сам стань справедливым начальником.
Не, в самом деле. 15 лет в разработке! Взрослый дядька! А сопли развел как маленький ребенок!
Наверное фиговый из меня психоаналитик. Извините ...
mBlaze
05.12.2024 05:38Смешные комментарии выше, наверное менеджеры эффективные писали.)
Автор то прав в той части, что есть такие компании где менеджер всегда прав, а если не прав смотри п1. Менеджер всегда прав. Ещё сектанты эти со всякими срамами, аджайлами и ретроспективами во главе с мастером этого действа и подгонкой КПИ чтоб быть лучшим стримом)), смешно со стороны, участвовать грустно.
Есть такие компании где инициатива по оптимизации процесса заворачивается менеджером с формулировкой, что это выстраданный процесс и менять его не будем, при этом соглашаясь, что он сложный, но всем тяжело и все по нему работают, вопрос зачем, остаётся без ответа.
Под многими статьями манифестами из личного опыта, комментарии вида "найди другую компанию" или "сам стань лидом". Но чтоб стать лидом или менеджером нужно занять либо уже занятое место, либо тебе выделили команду, а на это нужен бюджет и собственно команда и проект под команду, ни кто не пишет займи мое место лида и пойми меня))). А что касательно смены места работы, вы так пишите, как будто это, как два пальца об асфальт, как минимум какой менеджмент в другой компании это черный ящик, пока ты в этот ящик не сыграл)). Не будешь же раз в три месяца компании менять, хэры осудят и не поймут и больше не позовут на собеседование.:)
Да, и одно скажу точно, в этом истина - далее ты либо принимаешь правила игры там где работаешь, либо тебя слышат и что-то меняется, либо терпишь до нового оффера, UPD:а забыл - тебя ещё могут попросить уйти раньше нового оффера.
22 года или около того в странном ИТ, хотел бы продавать зонтики или варить кисели для пятерочки, но пока не выйти из айти.)
Notactic
05.12.2024 05:38Кажется, вы выбираете сомнительные компании.
Выход просто, что то не нравится в компании, начинаете это проговаривать и предлагать свои идеи. Не получилось? Говорим "спасибо, досвиданья". Все-же просто. Человек с 15и летним опытом, явно на рынке нужен.
P.S. Какие-то оценки эффективности никогда не встречал. Странная какая то штука. Возможно повезло просто.
mBlaze
05.12.2024 05:38Вы серьёзно?) это же не в телефон пальцем тап тап, чтобы компанию сменить и кто сказал, что там менеджеры адекватные? Как часто Вы меняли работы чтобы найти комфортную среду, удивите меня ответом пожалуйста. И если можно какой у Вас опыт и роль на данный момент, а то вдруг вы тимлид в третьем поколении.)
Notactic
05.12.2024 05:38Мой опыт работы в it ~9-10 лет. Когда был зелёный, тыкался во все направления, просто быстро надоедало и казалось, что не моё. Последние 5 лет, я фронтенд разработчик. Сейчас синьор vue/angular. Предлагали пойти в лиды, отказался, так как хлебом не корми, дай писать код.
Так вот, в том то и дело, что я не менял работу, чтобы найти комфортную среду. Ну не сложилось попасть в токсичную компанию. Но часто менял работу, чтобы поднять свою зарплату. Поэтому и говорю, что это просто. Если я выхожу на рынок и хожу выбираю из офферов самый жирный. То вы с таким опытом, явно нужнее.
Но, всё равно, когда меня, что то не устраивает, я открыто об этом говорю на дейликах/ретро.
mBlaze
05.12.2024 05:38Поколение... "Если, что-то не так, смени компанию, в чем проблема" - вы откуда такие, вы компании будете менять, как перчатки, вас через 10 лет ни куда не позовут. Кому нужен не стабильный сотрудник, вы о чем вообще? Как нанимать человека, который в случае любой трудности или то, что ему не нравится менеджер - увольняется? Мы там, так-то, за деньги - да. Ну и плюс желание изменить это говорит о мотивации, что человек топит за свою историю, историю в компании куда он пришел, часть работы это идея, ты создаёшь среду. А чтобы создать её нужно сначала заработать авторитет своей работой, на одном месте и тогда тебя, хотя бы лид будет слушать, уже хорошо, более того у вас все равно будут тёрки если ты человек инициативный и со своим видением процессов, на если вы говорите и обсуждаете уже плюс жирный.
Но будем откровенны многие просто берут задачи из бэклога и делают, это их работа и она им нравится. Тот кто выходит за эти рамки натыкается на барьеры, но именно у этого человека больший потенциал, он готов улучшать и менять.
И, собственно лидам особенно и менеджерам выше этот потенциал не нужен, они его в 90% не замечают и не ценят, у них свои задачи, КПИ КРС КП и вот это всё, разработчик должен делать задачи, точка. А они уже знают и сделали, как лучше. Даже если это не лучше.)
При этом у меня есть примеры руководителей очень крутых, лидов, в командах где я работал, а есть откровенно болото, но я не менял компании лишь потому что меня не слышат, меня нанимали на работу для другого. И история должна начинаться с этого, я делаю бизнесу хорошо и тогда совесть чиста, а тимлид или выше может быть каким угодно весёлым)
Notactic
05.12.2024 05:38Вы всё усложняете. Компания не царь и бог. У вас с ней взаимовыгодные отношения. Условия работы, обговариваются на собеседовании. И если ваши условия и условия компании сходятся - вы сотрудничаете. Всё, не больше, не меньше.
Если компания в одностороннем порядке решила изменить условия вашего сотрудничества. Ну, например решила, что не плохо бы следить, что я там в рабочее время делаю(однажды была такая инициатива, но я уже собирался уволится). Я имею полное право, не мириться с этим и говорю "спасибо, наше сотрудничество было приятным, досвиданья".
Или банально интересные и сложные задачи закончились. Какой смысл сидеть? Из за классных коллег?
Короче, мы меняем услуги на деньги и интересные задачи. Для меня, честно говоря, хотелки бизнеса тоже вторичны, главное мои хотелки.
Где минусы? :D
SellerOfSmiles
05.12.2024 05:38"вас через 10 лет ни куда не позовут"
Нас и сейчас никуда не зовут. Что поменяется-то? Я такие страшилки слышу всю свою жизнь. Меняется только модель поведения, которую оратор преподносит как деструктивную.
У меня сейчас три работы и на всех у меня замечательные вежливые и справедливые начальники, которые периодически рассказывают мне как они меня ценят, когда платят зарплату. Попал бы я в такое положение если бы не менял работы как перчатки всю свою жизнь?
Мне кажется тут проблема не в начальниках, а в том что специалисты не умеют выбирать себе работу. Да я в курсе что IT-шников сейчас как собак нерезаных, а вакансий больше не стало, но сути выбора работы это не меняет. Если вы идете в контору, где вас просят подождать в очереди, заполнить анкету, выполнить тестовое задание на неделю работы и потом еще и хамят на собеседовании, то с чего вы взяли что в процессе работы вас кто-то будет уважать и относиться к вам справедливо? Они уже убедились что уважать вас не нужно, т.к. вы сами себя не уважаете...
mBlaze
05.12.2024 05:38И давайте не забывать, что менеджер имеет менеджера, а тот лида и каждый по цепочке хочет быть героем и звездой, а не только вы)
vvm13xx
05.12.2024 05:38"Но такая оценка поверхностна и несправедлива. Вот реальный случай:
Петр выполнил 15 задач за месяц и сделал в них 5 ошибок.
Василий — 4 задачи с 4 ошибками.
Менеджер может запомнить, что Петр часто ошибается, не обращая внимания на то, что он сделал гораздо больший объем работы. "
Тоже поверхностно, потому что неизвестно, что за задачи. Может, одна задача Василия сложнее, чем 15 задач Петра. Причём и объём работы, и сложность (не обязательно) в количестве строк в коде отражаются.
pavelsha
Перечитайте текст. Подумайте всё ли хорошо в окружении, которое описываете и Вашим положением в нём, а также в восприятии ситуации. Пока получатся, "шевалье д'Артаньян и кругом п...ы".
А ещё или постарайтесь убрать из текста и головы слова типа "доносить" в таких ситуациях, или добляйте ещё и понятия "покрывать", "круговая порука" ( "омерта", если Вам близка итальянская культура ;-)
abryazgin
Поддержу. Дать обратную связь постановщику, где, по вашему мнению, он ошибся, это нормально. Тут 2 варианта. Либо он ошибся и исправит, либо ваше понимание задачи неверное (может, тех задание не содержит очевидной для постановщика информации).
Без обратной связи ничего не изменится. Надо только научится её корректно давать, не переходя на личности.