Программисты — молодцы. Они делают важные вещи, оживляют сайты и базы данных, помогают бизнесу и вообще всячески стараются. Раньше все хотели быть космонавтами, сейчас все хотят быть программистами — это логично, ведь отовсюду рассказывают, как легко и просто можно зарабатывать по 100 тысяч в месяц за код на удалёнке. И всё это звучит хорошо, если вы тоже программист.
Проблема в том, что есть люди, которые выбрали другую специальность, но им по работе постоянно приходится сталкиваться с программистами. И это иногда бывает тяжело.
Дело тут даже не в споре «технари против гуманитариев» — дело в разном подходе и взгляде на вещи. Мы собрали самые популярные проблемы, которые возникают при работе с программистами, и возможные пути их решения. Используйте на свой страх и риск.
Ситуация 1. Неправильная оценка сроков
« 3.03. Обсуждали сроки. Выпили 3 ящика пива. Петрович говорит, что тут всей работы на 4 месяца. Значит, на самом деле 8. В итоге в контракте записали 12, хотя раньше, чем за 16, вряд ли управимся.
Если бы программисты строили дома
Это обычное дело для программиста (на самом деле, для кого угодно). Никто не умеет оценивать сроки, пока не попрактикуется достаточно.
Решение. Использовать методологии разработки и оценки трудоёмкости. Если вы менеджер проектов, вы уже и так знаете про agile и scrum. Если не знаете — найдите ближайшего менеджера проектов и спросите у него, он поделится книжками, статьями и расскажет всё о гибких методологиях. Лично я советую книгу Майка Кона «Agile: оценка и планирование проектов».
Если на книги времени нет и вы ничего не понимаете в разработке, задайте тимлиду простой вопрос: «Из чего состоит оценка?». Если вам всё разложили по полочкам и объяснили, почему так — оценка близка к адекватной.
Оценка — не срок. Если вам в пятницу говорят «Сделаю к следующей пятнице», а оценка — 40 часов, задумайтесь. Уточните, когда человек будет заниматься другими задачами, и корректно ли он вообще оценивает время. Здесь поможет понимание того, как устроен цикл разработки в вашей компании, и на каких этапах могут быть замедления.
Ситуация 2. Исправлять ошибки неинтересно
« 4.02. Алекс доказывает, что он не виноват. Просто 12 этажей Сидорова на 4 метра выше и на 5 метров шире, чем 12 этажей Петровича. Выяснилось, что они строили из разных панелей. Но Алекс все равно ламер, поскольку его крыша не подходит по размеру ни одному из вариантов. Его шахта лифта, кстати, тоже.
Потому что кодить интересно, а поддерживать — нет. То же самое с техническим заданием — иногда заказчик что-то не уточнил в задании до конца, а программист сделал как было написано и уже переключился на другой проект или пошёл осваивать Super.Express.Double.G.Ultra.js. А вам вот уже точно никак без баннера, который нужен для запуска рекламной кампании, а его нет.
Решение. Находить общий язык в команде и организовывать процессы так, чтобы поддержка и доработка кода была одним из этапов работы, а не авралом и стихийным бедствием для всех разработчиков.
Ситуация 3. Не уточнили задачу и сделали не то
Первый этаж готов! Показали его заказчику. Он интересовался, почему в разных комнатах разная высота потолков, почему из стен вываливаются кирпичи и почему в доме нет подъезда, а влезать приходится через окно. Объяснили ему, что это специальные ограничения демо-версии. Уходим на праздники, гордые собой.
Если бы программисты строили дома
Решение. Помогает совместное планирование до начала работы, где менеджер проекта объясняет, чем занимается вся команда. У любой задачи есть причина — например, аналитики посчитали, что нужно передвинуть кнопку в интерфейсе, потому что там в два раза повысится конверсия.
Здесь же помогают прототипы и демки — и всё это вы можете быстро сделать своими силами, чтобы разработка уже сидела и думала, как это всё реализовать.
Ситация 4. Сделали не то и до последнего не могут это признать
» 3.03. Убедили заказчика, что нам нужен еще день для финального тестирования. М-да, ну мы вчера и наработали... А в общем, не все так страшно. Ну что с того, что некоторые двери находятся в полу или в потолке, либо ведут с десятого этажа прямиком на улицу, в некоторые квартиры в принципе невозможно попасть, санузел кое-где совмещен с кухней, в половине дома нет воды, в другой половине - электричества, канализация обрывается на шестом этаже, а лестницу между восьмым и девятым пришлось сделать веревочной? Главное - провести заказчика правильным маршрутом. И еще - успеть до завтра развесить на месте исчезнувших окон картинки с изображением заоконных пейзажей.
Если бы программисты строили дома
Так бывает — написано одно, а сделано другое. Или то, но по-другому. Или как-то ещё, но результат вас не устраивает, а программисты не признают, что это всё-таки баг, а не фича. Такое бывает, если техническое задание почему-то оказалось не очень — в нём отсутствуют требования, описание результата или заказчик вообще сам не понимает, чего хочет.
Решение. Корректное и полное техническое задание. Если речь о сайте — можно сделать прототип страницы, блока или элемента, чтобы показать его разработке. Для создания прототипов пригодятся навыки работы в графическом редакторе (например, Photoshop или Figma) и базовой вёрстки на HTML и CSS.
Недаром всё больше менеджеров, дизайнеров и маркетологов изучают вёрстку и программирование — способность говорить на одном языке с программистами и понятно доносить задачу позволяет быстрее запускать любые проекты и делать это качественно.
Теперь ваша очередь — расскажите в комментариях, как вам удаётся общаться с программистами, чем они бесят и чем радуют, и чего ни в коем случае нельзя делать, чтобы работать с ними в одной команде долго и счастливо.