Разборы

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

Если бы программисты строили дома...

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

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

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

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

Обсуждали сроки. Выпили 3 ящика пива. Петрович говорит, что тут всей работы на 4 месяца. Значит, на самом деле 8. В итоге в контракте записали 12, хотя раньше, чем за 16, вряд ли управимся.

Источник: если бы программисты строили дома

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

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

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

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

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

Петрович добрался до пятого этажа. Горд собой. Обратили его внимание на тот факт, что его стена наклонена под углом 40 градусов. Он ругался, кричал, что мы ламеры и ничего не понимаем. Потом обещал подумать.

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

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

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

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

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

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

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

Петрович признал, что со стеной действительно имеется проблема. Говорит, что неправильно положил какой-то кирпич. Но чтобы понять, какой именно, надо перебрать их все. Проще все снести и построить заново.

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

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

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

Приходил заказчик. Спрашивал, нельзя ли внести в проект небольшие изменения. В частности, вместо 12-этажного дома построить поселок из деревянных коттеджей, соединенных туннелями. Он прочитал, что на Западе сейчас так модно. Нейтрализовали Алекса прежде, чем тот успел открыть рот, и вежливо, но твердо объяснили заказчику, что он не прав.

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

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

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

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

Алекс доказывает, что он не виноват. Просто 12 этажей Сидорова на 4 метра выше и на 5 метров шире, чем 12 этажей Петровича. Выяснилось, что они строили из разных панелей. Но Алекс все равно ламер, поскольку его крыша не подходит по размеру ни одному из вариантов. И шахта лифта, кстати, тоже.

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

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

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

Первый этаж готов! Показали его заказчику. Он интересовался, почему в разных комнатах разная высота потолков, почему из стен вываливаются кирпичи и почему в доме нет подъезда, а влезать приходится через окно. Объяснили ему, что это специальные ограничения демо-версии. Уходим на праздники, гордые собой.

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

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

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

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

Главное — провести заказчика правильным маршрутом. И еще — успеть до завтра развесить на месте исчезнувших окон картинки с изображением заоконных пейзажей.

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

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

Пример ТЗ для программиста. Описываем проблему, даем прототип формы подписки и подробно рассказываем, чего хотим
Пример ТЗ для программиста. Описываем проблему, даем прототип формы подписки и подробно рассказываем, чего хотим

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