Время чтения:
6 мин.Время чтения:
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 или другая программа. Учет времени должен быть, чтобы хотя бы представлять, какие были трудозатраты. В нашей команде это не выступает в форме жесткого контроля, скорее для оценки производительности. Контроль, конечно, нужен, поскольку у разработчиков присутствуют творческие задачи, которые интересно выполнять. Но бывают и задачи, которые не хочется делать, рутинного характера. Однако жесткий контроль может негативно влиять на производительность, поэтому здесь нужен баланс.
Выделим три сценария развития событий, если вы обнаружили эти признаки у своих программистов: