Чужие ошибки, ваши последствия: взгляд изнутри на несправедливость в IT

Тяжесть решений: кто же на самом деле несет ответственность в IT?

Для начала представлюсь - я разработчик с более чем 15-летним стажем. За это время я работал в самых разных компаниях — от маленьких стартапов до крупных корпораций, в одиночку и в больших командах. Хочу рассказать о несправедливости в IT, с которой мне пришлось столкнуться.

Кто виноват?

Так уж сложилось, что все задачи, которые поручают разработчику, автоматически предполагают, что за любые ошибки он несет полную ответственность. Но редко кто задумывается, что в процесс вовлечено множество людей, и каждый из них влияет на конечный результат.

Пример (оценка разработчиков менеджерами).

Оценка разработчиков менеджерами она строится на воспоминаниях: этот сотрудник часто ошибается, а этот — редко. Но такая оценка поверхностна и несправедлива. Вот реальный случай:

• Петр выполнил 15 задач за месяц и сделал в них 5 ошибок.

• Василий — 4 задачи с 4 ошибками.

Менеджер может запомнить, что Петр часто ошибается, не обращая внимания на то, что он сделал гораздо больший объем работы. (Пропорционально ошибок у него даже меньше).

Или другой пример:

• Петр выполнил 15 задач с 21 ошибкой (все исправлены).

• Василий — 4 задачи с 4 ошибками.

На первый взгляд, кажется, что Петр некомпетентен. Однако он сделал больше задач, а значит, принес больше пользы компании. Логично, что с ростом объема работы вероятность ошибок увеличивается. Тогда почему менеджеры учитывают одни факторы не учитывая другие при оценке исполнителей?

А что считать ошибками?

Нередко разработчиков винят за то, что они сделали ровно то, что было описано в задаче, но этого оказалось недостаточно. Например, постановщик задачи недостаточно подробно описал требования. Кто здесь виноват? Если ошибки оцениваются только у разработчиков, то ошибки всех принимавших участие в задаче — становятся виной только одного разработчика. (а на самом деле могут быть виноваты все от рукоdjlcndf, до qa менеджера, или других разработчиков, или даже ошибка есть а не виноват никто по ряду причин).

К тому же критика менеджеров или руководства в IT воспринимается как дурной тон. Разработчик вряд ли станет доносить на постановщика задачи о его ошибках, ведь это может плохо сказаться на его репутации и привести к последующему увольнению.

Проблема двойных стандартов

Ситуация усугубляется двойными стандартами руководства.

Если разработчик делает только то, что от него просят, ему говорят, что он недостаточно инициативен. Если он предлагает улучшения или сам придумывает задачи, его упрекают в том, что он выходит за рамки. (и нужно исправлять баги после нового не нужного функционала, или там лишний раз проверять и тестировать).

Менеджеры и заказчики все чаще перекладывают свои обязанности на разработчиков:

• Сам ставь себе задачи.

• Сам разбирайся в бизнес-логике проекта.

• Сам предлагай решения.

Мало того, разработчику приходится выполнять работу за смежные отделы. Например, писать фронтенд, заниматься дизайном UX/UI, тестированием или даже настройкой серверов.

Не менеджеры, а проблема

Часто проблемы вызваны неработающими бизнес-процессами. Например:

• Плохо налажена коммуникация между командами.

• Несогласованная работа нескольких разработчиков над связанным кодом приводит к конфликтам.

• Руководители назначают нереалистичные сроки, игнорируя оценки сотрудников.

• Разработчики боятся давать честные прогнозы, опасаясь критики. В результате сроки искусственно занижаются, что приводит к срывам.

В чём корень проблемы?

Все сводится к тому, что у кого есть власть, тот формально оказывается «прав». Ошибки руководства нельзя исправить потому что начальство не критикуют, и начальство из раза в раз может делать одни и теже ошибки, не пытаясь совершенствоваться.

Иерархическая структура в IT часто лишена справедливости. Успехи компании — заслуга руководства, а все неудачи возлагаются на исполнителей.

Задачи разработчиков сводятся не к улучшению проектов, а к угадыванию предпочтений начальства и избеганию конфронтаций.

Что делать?

Проблема требует системных изменений.

• Четко фиксировать ответственность на каждом этапе работы.

• Объективно оценивать результаты, учитывая объем выполненных задач.

• Налаживать бизнес-процессы и обеспечивать честную коммуникацию внутри компании.

• Ставить реальные сроки, опираясь на мнение тех, кто выполняет работу. (Не пытаться давить на сроки выполнения обосновывая тем что кто-то другой считает иначе, если другой разработчик считает что можно сделать в 3 раза быстрей то пусть и делает, это будет его ответственность, а назначать сроки по чужому мнению это несправедливо).