Типичные проблемы программистов: как их решить, если вы — заказчик

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

Дело тут даже не в споре «технари против гуманитариев» — дело в разном подходе и взгляде на вещи. Мы собрали самые популярные проблемы, которые возникают при работе с программистами, и возможные пути их решения.

Неправильная оценка сроков

Это обычное дело для программиста (на самом деле, для кого угодно). Никто не умеет оценивать сроки, пока не попрактикуется.

Решение. Использовать методологии разработки и оценки трудоёмкости. Если вы менеджер проектов, вы уже и так знаете про agile и scrum. Если не знаете — найдите ближайшего менеджера проектов и спросите у него, он поделится книжками, статьями и расскажет всё о гибких методологиях. Лично я советую книгу Майка Кона «Agile: оценка и планирование проектов». 

Если на книги времени нет и вы ничего не понимаете в разработке, задайте тимлиду простой вопрос: «Из чего состоит оценка?». Если вам всё разложили по полочкам и объяснили, почему так — оценка близка к адекватной.

Оценка — не срок. Если вам в пятницу говорят «Сделаю к следующей пятнице», а оценка — 40 часов, задумайтесь. Уточните, когда человек будет заниматься другими задачами, и корректно ли он вообще оценивает время. Здесь поможет понимание того, как устроен цикл разработки в вашей компании, и на каких этапах могут быть замедления.

Плохая реакция на критику

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

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

1. Давайте обратную связь, когда вас об этом просят.
2. Говорите о делах, а не о личности человека.
3. Будьте конкретными — используйте факты, а не оценки.
4. Сбалансируйте хорошее и плохое. И начинайте с хорошего, потом плохое, потом снова хорошее.
5. Подбирайте стиль обратной связи в зависимости от сотрудника. Кому-то можно в лоб и прямо, а кому-то — только окольными путями.

Хорошо, если разработчики не обижаются на слово «отстой». Но если вы такого не говорите, то можно приходить с формулировкой «О, кажется, тут у тебя потерялась штука из описания задачи. Смотри, её нужно было вот так сделать. Поправишь сегодня?».

Важную роль играет неформальное общение — на условном перекуре можно вспомнить про плохо сделанную задачу и попросить быть повнимательнее, привести пару примеров. Ни в коем случае не сравнивайте человека с условным Колей, типа он молодец, а ты — нет.

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

Срочно переписать весь чужой код

Чужой код обычно достаётся по наследству и не всегда работает хорошо. Конечно же, его хочется сразу переписать. Конечно же, на Super.Express.Double.G.Ultra.js.

Решение. Найти баланс между задачами бизнеса и разработки. Поговорите с тимлидом программистов, уточните, нет ли чего-то критичного в старом коде. Если код не мешает работе над продуктом — оставляйте его.

Выбор неподходящей (но очень интересной лично программисту) технологии

Вышел новый Super.Express.Double.G.Ultra.js? Отлично, теперь на нём срочно нужно сделать загрузчик фото, а весь остальной проект на реакте подождёт. А заодно подождут и все участники процесса, которым там какие-то фичи нужны.

Решение. Мягко намекнуть разработчику на то, что фреймворк клёвый (вы это вчера читали на Хабре), но проект уже послезавтра запускать, и времени на эксперименты вот вообще никак совершенно нет. 

Перед началом следующего проекта можно устроить большой созвон всей командой и обсудить, на чём писать. А вот сейчас — уже никак, нужно просто сделать быстро и чтобы ничего не развалилось сразу после запуска.

Исправлять ошибки неинтересно

Потому что кодить интересно, а поддерживать — нет. То же самое с техническим заданием. Иногда заказчик что-то не уточнил в задании, а программист сделал, как было написано, и пошёл осваивать Super.Express.Double.G.Ultra.js. В итоге, вам нужен баннер для рекламной кампании, а его нет.

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

Не уточнили задачу и сделали не то

Решение. Помогает совместное планирование до начала работы, где менеджер проекта объясняет, чем занимается вся команда. У любой задачи есть причина — например, аналитики посчитали, что нужно передвинуть кнопку в интерфейсе, потому что так в два раза повысится конверсия. 

Здесь же помогают прототипы и демки. Их можно быстро сделать своими силами, например, в графическом редакторе, чтобы разработка сидела и думала, как это реализовать.

Сделали не то и до последнего не могут это признать

Так бывает — написано одно, а сделано другое. Результат вас не устраивает, а программисты не признают, что это всё-таки баг, а не фича. Такое бывает, если техническое задание почему-то оказалось не очень — в нём отсутствуют требования, описание результата или заказчик вообще сам не понимает, чего хочет.

Решение. Корректное и полное техническое задание. Если речь о сайте — можно сделать прототип страницы, блока или элемента, чтобы показать его разработке. Для создания прототипов пригодятся навыки работы в графическом редакторе (например, Photoshop или Figma) и базовой вёрстки на HTML и CSS.

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