6 признаков, что вам стоит заменить разработчика
Качество работы программистов может сильно отличаться. У одних проектных команд разработчиков проекты сдаются в срок с минимальным количеством ошибок. Однако проектные менеджеры часто сталкивались с ситуациями, когда разработчики неоднократно нарушали сроки, продукт кишел багами и в результате код приходилось переписывать.
Чтобы разобраться, какие признаки в работе команды разработчиков дают основание задуматься об их замене, мы поговорили с Виталием Макс, техническим директором компании «IQ Dev», который 7 лет занимается управлением IT-командами в области веб-программирования.
Деструктивно нарушение сроков сказывается не только на работе с клиентами, но и на внутренней координации проектной команды. Если программисты постоянно «кормят коллег завтраками» о том, что скоро их часть проекта будет сдана, а в итоге не выполняют задачи в срок, работа коллег тоже страдает при этом.
«Сроки сильно зависят от воспитания, от того, где и как разработчик учился программировать. Например, в нашей команде изначально каждого программиста учат правильно оценивать и соблюдать сроки разработки. Да, вначале неопытный джуниор может неправильно рассчитать срок — оценил в 3 часа, а по факту выполнил за 9 часов. Однако это нормально, потом идет разбор, почему программист неверно оценил время. С этим помогает опытный team-лид. Крайне важно, чтобы сроки соблюдались, у нас в команде это напрямую влияет на заработную плату программистов».
Не вписываются в сроки проекта
В СМИ программирование часто подается как некий творческий акт, а образ самого программиста сопоставим с образом художника, пишущего картину. В мире взаимодействия с клиентами ни одного заказчика не устраивает, когда сроки срываются, ведь потерянное время — это потерянные деньги.
Программисты не дают ответы на вопросы по разработке
Если на вопросы о проекте разработчики не дают однозначных ответов - это повод задуматься о компетенциях программистов, ведь автор знает свое творение до самых мельчайших деталей. Конечно, если говорить о сложных продуктах, где участвует проектная команда разработчиков, то выводы не обязательно столь однозначны. Компетентность в вопросах по разработке связана с привязкой к специализации IT-специалиста. Например, программист не занимался интеграцией с сервисами, скажем, с «iiko» и «1С». Или разработчик не работает с администрированием серверов. Но у него много опыта в другом направлении. Естественно, что на вопросы о интеграции сайта с 1С имеет смысл задавать тому сотруднику, который ей занимается. Еще один фактор - это коммуникационные скиллы сотрудника. Программист способен владеть техническими навыками, но не суметь детально и понятно рассказать о результатах работы другим людям. Этот навык приходит с опытом и важен он в первую очередь для team-лидов, которые общаются с заказчиками и project-менеджерами. Однако, если разработчик не способен дать ответа даже на ломаном техническом языке на вопрос из своей зоны компетенций - это повод задуматься.
Говорят, что задумку невозможно реализовать
Современные методы программирования почти не ограничены и дают инструментарий для того, чтобы достичь амбициозные цели. В языках программирования и платформах созданы библиотеки, упрощающие разработку в таких высокотехнологичных сферах, как машинное обучение, анализ больших данных, искусственный интеллект. Если разработчики говорят, что задумку невозможно реализовать, вероятно это попытка слукавить. Это говорит скорее о нежелании обучаться и развиваться, чтобы реализовать эту идею. Сотрудникам комфортнее выполнять то, что уже понятно и опробовано много раз.
«В разработке нет ничего невозможного, нет того, что нельзя было бы реализовать. Вопрос стоит только в том количестве денег и времени, которое потратит при этом заказчик и в том, оправдывают ли такие затраты бизнес-цели заказчика».
«Плохой код убивает»
Известна шутка о программисте Джо, который написал забагованный код в программе и каждый пользователь тратил 15 минут на то, чтобы справиться с багом. А так как программу скачали 10 миллионов пользователей, то общие затраты времени составили 150 млн. минут. Что составляет, при округлении, 7 человеческих жизней, если вычесть из них часы сна. Таким образом, Джо «убил» 7 человек. Однако не читаемый код или код с ошибками «убивает» время не только пользователей, но и разработчиков, пытающихся его прочитать. Профессионал в программировании следует набору общепринятых правил касательно написания кода, например, PSR стандартам. Если человек достиг профессионального уровня в написании кода, то так или иначе приходит к таким принципам написания кода, как «SOLID, DRY, KISS», соблюдение которых делает код понятным. Код разработчика-непрофессионала тяжело прочитать и понять, даже будучи профессионалом. Если сотрудник говорит, что не понимает код другого специалиста, то скорее это говорит о слабом профессионализме человека, написавшего код. В идеале, код пишется так, чтобы его легко читали и senior-, и middle-, junior-разработчики.
Переделывают модули программы, которые написали на предыдущих этапах проекта
Это неприятная ситуация, поскольку опять же тратится время на переделывание предыдущих этапов работы. При этом необходимо разобраться, в каких ситуациях это по-настоящему говорит о слабом профессиональном уровне программистов: Первая ситуация, когда в процессе работы над проектом меняются требования и предыдущий модуль не покрывает потребности заказчика. Скажем, изначально заказчик хотел сделать интернет-магазин только с серыми айфонами, но уже в ходе работы над проектом решил расширить ассортимент и добавить белые. Виталий Макс «Например, возьмем модуль, который работает с API и в проект решили внести изменения - добавить на сайт новые поля. Реально реализовать модуль так, что он не будет автоматически запрашивать с API новые поля, обрабатывать их и отдавать. И это не серьезная проблема, доработка не займет много дней. Это не вина программиста, а нормальный рабочий процесс». Другая ситуация, когда доработки предыдущих модулей происходят из-за того, что разработчик не увидел архитектуры. В этом случае налицо ошибка программиста. Однако, если такую ошибку допускает неопытный сотрудник - это нормально. Но если у senior-разработчика постоянно возникает ситуация, когда он переделывает предыдущие этапы работы - это тревожный звонок.
Не могут объяснить, что сделали за день, неделю
Если разработчик не способен объяснить, что сделал за день или за неделю, скорее всего он не сделал ничего, продвигающего проект к результату. Когда вы не знаете, чем занимаются программисты, вы не контролируете процесс создания продукта.
«Вопрос о контроле за разработчиками является философским. Использование технологий по учету времени и управлению проектами внутри IT-команд обусловлено необходимостью. Будь то Redmine, ClickUp или другая программа. Учет времени должен быть, чтобы хотя бы представлять, какие были трудозатраты. В нашей команде это не выступает в форме жесткого контроля, скорее для оценки производительности. Контроль, конечно, нужен, поскольку у разработчиков присутствуют творческие задачи, которые интересно выполнять. Но бывают и задачи, которые не хочется делать, рутинного характера. Однако жесткий контроль может негативно влиять на производительность, поэтому здесь нужен баланс».
Что делать, если вы обнаружили эти признаки у своих разработчиков
Выделим три сценария развития событий, если вы обнаружили эти признаки у своих программистов:
- Заменить разработчиков на новых. Найм одного разработчика стоит в среднем 2 месячных оклада работающего сотрудника. Учитывая, что оклад программиста составляет в районе 150 - 200 тыс. рублей, стоимость найма составит 300 - 400 тыс. рублей. Это только один человек и остается риск, что через время вы столкнетесь с теми же проблемами, что были и у предыдущих сотрудников
- Вложить деньги в развитие разработчиков. Плюс в том, что в этом случае наймодатель вкладывается в человеческий капитал, проявляете себя как заботливый работодатель. Однако риски состоят в том, чтобы потратить серьезную сумму денег (на обучение, перестройку бизнес-процессов, внедрение систем управления проектами и т.д.) и времени (перестройка внутренних процессов компании ресурсоемкое дело), а в итоге не получить должного эффекта, поскольку оказывают влияние на итоговую эффективность еще и личные качества разработчиков, которые не исправить обучением.
- Отдать проект на аутсорсинг в ту компанию, где процессы выстроены, сроки контролируются и не срываются, за компетентностью программистов следят и развивают. В этом варианте есть несколько больших плюсов: аутсорсинговая компания несет финансовую ответственность за выполнение проекта, разработка проекта в аутсорсинговой компании стоит часто стоит дешевле, чем содержание собственного штата программистов, а качество конечного продукта при этом выше. Риски работы с подрядчиком тоже есть. Главный из них - это выбор надежной компании, с опытом и сильной командой. Если компания не соответствует этим критериям, то преимущества работы сводятся на нет.
