Программисты — молодцы. Они делают важные вещи, оживляют сайты и базы данных, помогают бизнесу и вообще всячески стараются. Раньше все хотели быть космонавтами, сейчас все хотят быть программистами — это логично, ведь отовсюду рассказывают, как легко и просто можно зарабатывать по 100 тысяч в месяц за код на удаленке. И все это звучит хорошо, если вы тоже программист.
Проблема в том, что есть люди, которые выбрали другую специальность — например, дизайнеры, менеджеры или маркетологи — и им по работе постоянно приходится сталкиваться с программистами. И это иногда бывает тяжело.
Дело тут даже не в споре «технари против гуманитариев» — дело в разном подходе и взгляде на вещи. Мы собрали самые популярные проблемы, которые возникают при работе с программистами, и возможные пути их решения. Используйте на свой страх и риск.
Неправильная оценка сроков
«3.03. Обсуждали сроки. Выпили 3 ящика пива. Петрович говорит, что тут всей работы на 4 месяца. Значит, на самом деле 8. В итоге в контракте записали 12, хотя раньше, чем за 16, вряд ли управимся».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Это обычное дело для программиста (на самом деле, для кого угодно). Никто не умеет оценивать сроки, пока не попрактикуется достаточно.
Решение. Использовать классные методологии разработки и оценки трудоемкости. Если вы менеджер проектов, вы уже и так знаете про Agile и Scrum. Если не знаете — найдите ближайшего менеджера проектов и спросите у него, он поделится книжками, статьями и расскажет все о гибких методологиях.
Если рядом нет ни одного менеджера проектов, найдите книжку Майка Кона «Agile: оценка и планирование проектов», и начните ее читать. Когда разберетесь в основах, прочитайте «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения» Тома ДеМарко и Тимоти Листера. Эта книга не для новичков, но хорошо помогает понять нюансы управления проектами.
Если на книги времени нет, и вы ничего не понимаете в разработке, задайте тимлиду простой вопрос: «Из чего состоит эта оценка?». Если вам все разложили по полочкам и объяснили, почему так — оценка близка к адекватной.
Оценка — не срок. Если вам в пятницу говорят «Сделаю к следующей пятнице», а оценка — 40 часов, задумайтесь. Уточните, когда человек будет заниматься другими задачами, и корректно ли он вообще оценивает время. Здесь поможет понимание того, как устроен цикл разработки в вашей компании, и на каких этапах могут быть замедления.
Плохая реакция на критику
«2.10. Петрович добрался до пятого этажа. Горд собой. Обратили его внимание на тот факт, что его стена наклонена под углом 40 градусов. Он ругался, кричал, что мы ламеры и ничего не понимаем. Потом обещал подумать».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Несмотря на то, что программисты обычно брутально пишут код, брутально ходят на митапы и брутально меняют места работы, лучше не слишком их расстраивать неожиданной обратной связью. Например, не стоит прямо говорить, что продукт получился плохим, свежая фича не очень и вообще можно было бы лучше стараться. Все мы люди, и программисты — не исключение.
Решение. Научиться давать обратную связь. Есть несколько простых правил для обратной связи вообще кому угодно.
- Давайте обратную связь, когда вас об этом просят.
- Говорите о делах, а не личности человека.
- Будьте конкретными — используйте факты, а не оценки.
- Сбалансируйте хорошее и плохое. И начинайте с хорошего, потом плохое, потом снова хорошее.
- Подбирайте стиль обратной связи в зависимости от сотрудника. Кому-то можно в лоб и прямо, а кому-то только окольными путями.
Срочно переписать весь чужой код
«5.10. Петрович признал, что со стеной действительно имеется проблема. Говорит, что неправильно положил какой-то кирпич. Но чтобы понять, какой именно, надо перебрать их все. Проще все снести и построить заново».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Чужой код обычно достается по наследству и не всегда работает хорошо. Конечно же, его хочется сразу переписать. Конечно же, на Super.Express.Double.G.Ultra.js (см. следующий пункт).
Решение. Найти баланс между задачами бизнеса и разработки. Поговорите с тимлидом программистов, уточните, нет ли чего-то критичного в старом коде. Если он не мешает работе над продуктом — работайте над продуктом дальше и программисту об этом расскажите.
Выбор неподходящей, но интересной лично программисту, технологии
«Приходил заказчик. Спрашивал, нельзя ли внести в проект небольшие изменения. В частности, вместо 12-этажного дома построить поселок из деревянных коттеджей, соединенных туннелями. Он прочитал, что на Западе сейчас так модно. Нейтрализовали Алекса прежде, чем тот успел открыть рот, и вежливо, но твердо объяснили заказчику, что он не прав».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Вышел новый Super.Express.Double.G.Ultra.js? Отлично, теперь на нем срочно нужно сделать загрузчик фото, а весь остальной проект на реакте подождет.
Решение. Мягко намекнуть разработчику на то, что фреймворк клевый — вы это вчера читали на «Хабре», — но проект уже послезавтра запускать, и времени на эксперименты вот вообще никак совершенно нет.
Перед началом следующего проекта можно устроить большой созвон всей командой и обсудить, на чем писать, а вот сейчас — уже никак, нужно просто сделать быстро, и чтобы ничего не развалилось сразу после запуска.
Исправлять ошибки неинтересно
«4.02. Алекс доказывает, что он не виноват. Просто 12 этажей Сидорова на 4 метра выше и на 5 метров шире, чем 12 этажей Петровича. Выяснилось, что они строили из разных панелей. Но Алекс все равно ламер, поскольку его крыша не подходит по размеру ни одному из вариантов. Его шахта лифта, кстати, тоже».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Потому что кодить интересно, а поддерживать — нет. То же самое с техническим заданием — иногда заказчик что-то не уточнил в задании до конца, а программист сделал как было написано и уже переключился на другой проект или пошел осваивать Super.Express.Double.G.Ultra.js. А вам вот уже точно никак без баннера, который нужен для запуска рекламной кампании, а его нет.
Решение. Находить общий язык в команде и организовывать процессы так, чтобы поддержка и доработка кода была одним из этапов работы, а не авралом и стихийным бедствием для всех разработчиков.
Не уточнили задачу и сделали не то
«Первый этаж готов! Показали его заказчику. Он интересовался, почему в разных комнатах разная высота потолков, почему из стен вываливаются кирпичи и почему в доме нет подъезда, а влезать приходится через окно. Объяснили ему, что это специальные ограничения демо-версии. Уходим на праздники, гордые собой».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Решение. Помогает совместное планирование до начала работы, где менеджер проекта объясняет, чем занимается вся команда. У любой задачи есть причина — например, аналитики посчитали, что нужно передвинуть кнопку в интерфейсе, потому что там в два раза повысится конверсия.
Здесь же помогают прототипы и демки — и все это вы можете быстро сделать своими силами, чтобы разработка уже сидела и думала, как это все реализовать.
Сделали не то и до последнего не могут это признать
«3.03. Убедили заказчика, что нам нужен еще день для финального тестирования. М-да, ну мы вчера и наработали… А в общем, не все так страшно. Ну что с того, что некоторые двери находятся в полу или в потолке, либо ведут с десятого этажа прямиком на улицу, в некоторые квартиры в принципе невозможно попасть, санузел кое-где совмещен с кухней, в половине дома нет воды, в другой половине — электричества, канализация обрывается на шестом этаже, а лестницу между восьмым и девятым пришлось сделать веревочной? Главное — провести заказчика правильным маршрутом. И еще — успеть до завтра развесить на месте исчезнувших окон картинки с изображением заоконных пейзажей».
Из рассказа «Если бы программисты строили дома», автор неизвестен.
Так бывает — написано одно, а сделано другое. Или то, но по-другому. Или как-то еще, но результат вас не устраивает, а программисты не признают, что это все-таки баг, а не фича. Такое бывает, если техническое задание почему-то оказалось не очень — в нем отсутствуют требования, описание результата или заказчик вообще сам не понимает, чего хочет.
Решение. Корректное и полное техническое задание. Если речь о сайте — можно сделать прототип страницы, блока или элемента, чтобы показать его разработке. Для создания прототипов пригодятся навыки работы в графическом редакторе, например, Photoshop или Figma, и базовой верстки на HTML и CSS. Недаром все больше менеджеров, дизайнеров и маркетологов изучают верстку и программирование — способность говорить на одном языке с программистами и понятно доносить задачу позволяет быстрее запускать любые проекты и делать это качественно.
Теперь ваша очередь — расскажите в комментариях, как вам удается общаться с программистами, чем они бесят и чем радуют, и чего ни в коем случае нельзя делать, чтобы работать с ними в одной команде долго и счастливо.
Читайте также:
"Скажи нет наркотикам! И вообще, не разговаривай с наркотиками!" - так и тут. Код вообще последнее дело, но с него почему-то упорно начинают. Меня, когда учили на системотехника, мордовали видеть и целое, и части. И строить сверху-вниз, исходя из потребностей. Специальность "программист" по факту ущербна, если нет понимания окружения твоего кода. На практике, если человек начинал кодить в SAPе или в dbf-окружении, объяснять ему при переходе на oracle, например, что есть ресурсы и они конечны, та ещё морока. А всё почему - бессистемность и уровни абстракции. В целом, на любую профессию можно переложить, да.
А вот навыки системотехники здОрово помогли при освоении второй профессии, что как-бы намекает )))
Вы правы! Очень даже правы! Поделюсь своим опытом столетней давности, вдруг кто-то из молодых найдёт зрелые зёрна в этом и поставит на новый уровень.
Когда деревья были большими, существовала такая практика - не заказчикискал общий язык с программистом, а программист с заказчиком. Для этого мы даже проводили небольшие курсы, ликбез по прикладной задаче. Изучали азы бухгалтерии, например, или систему срабатывания датчиков предупреждения о пожаре. Или параметры баллистики. Только после этого программисту "разрешалось" приступать к работе. Именно из-за такого погружения в прикладную тему программисты ценились - часто они знали даже больше, чем спец в той области. Пишешь навигационную задачу - узнаешь такие тонкости, которые и штурманы не знали. Пишешь программу передачи больших массивово информации, невольно становишься связистом.
В шутку современное программирование я обзываю штукатурной работой.
Хватит разговаривать с программистами!
Начните разговаривать с бизнес-аналитиками, которые пишут ТЗ для программистов. Чем лучше они напишут ТЗ - тем меньше у вас будет проблем в дальнейшем.
Если вам уж очень хочется говорить с программистами - выберите настоящиго тимлида, который является наставником для остальных программистов. Его обнаружить достаточно легко - у него зарплата как у гендира или выше и ему 40+ лет. Он умеет общаться на языке бизнеса и переводить его на язык программистов.
. Евгений, по Вашим комментариям я угадываю, что Вы - профессионал в том, мимо чего я когда-то прошел где-то по краю. Вы наверняка имеете навык системного подхода. И таким как Вы надо излагать проблему, а не задачу. Но, к сожалению, мне опыт подсказывает, что Ваш стиль работы, скорее, исключение чем правило.
Своим предыдущим комментарием я хотел сказать, что подавляющая доля спецов (не только программистов, как правильно отметил В.Локтионов !) предпочитает иметь дело с задачами, а не с проблемами. Потому-то им и надо выдавать задания в виде задачи, а не проблемы. А для этого, представитель заказчика должен иметь некоторый опыт в работе подрядчика-программиста.
Владимир, мы пытаемся в этой дискуссии назвать одним словом слишком многое или слишком многих. Возможно, автор статьи (напомним, что это коллекция шуток) говорит о программистах как о чем-то однородном и как о едином целом. Отсюда и возник полушутливый вопрос, на каком же языке нам с ними общаться, когда это понадобится.
Но компьютеры и программирование (то есть создание некого кода, решающего определенную задачу) сейчас используются практически во всех отраслях и областях, начиная с наших телефонов - очень мощных компьютеров, многократно превосходящими по мощности все, на чем мы работали в описываемое Вами время. И мы не общаемся с разработчиками Google или Yandex, если нам нужно отправить почту или найти бензоколонку. Вопросы удобства и детали функционала с нами никогда не обсуждались. Хотите - пользуйтесь, нет - как угодно.
Проблема общения при начале разработки или в ходе проекта находится несколькими уровнями выше, чем разработка конкретного алгоритма или - тем более - кодирование. И это - до сих пор - одна из главных реальных проблем, непосредственно влияющих на успех проекта. В этои плане ничего не изменилось - люди, делающие общее дело, должны хорошо понимать друг друга.
Заказчик в данном контексте - это роль в проекте (или покупатель готового или полуготового ПО) со своими правами и обязанностями. Как формулируется проблема, на какие задачи и подзадачи она разбивается, какими средствами решается, в рамках какого проекта и этапа или подэтапа - обсуждается в рамках нормальной дискуссии с участием всех сторон. Общение идет на естественных языках, результаты согласуются и документируются.
Я предпочитаю начинать с высокоуровнего описания проблемы и согласовывать критерии успеха на самых ранних стадиях. Экономия времени на этом просто недопустима. Затем согласованные документы можно детализировать до необходимого разработчикам уровня. Тестирование показывает, все ли идет по плану. Если, как Вы говорите, задания выдаются в виде отдельных задач, а не проблемы, то кто-то на стороне заказчика должен отвечать за правильность такого разбиения, то есть за архитектуру системы. Возможно и такое, но это ведет к практически неизбежным конфликтам.
Честно говоря, не могу вспомнить, чтобы заказчику (кроме выделенных им технических представителей) в наших проектах приходилось согласовывать какие-то сугубые технические детали непосредственно с программистами.
Интересно, применяется ли такой подход в медицине ( ... когда заболит, найдите ближайшего доктора, он вам даст пару книжек, а потом лечите себя сами ...) или строительстве ( ... найдите прораба, он вам расскажет про раствор, даст пару телефонов заводов стройматериалов и альбом проектов, а потом постройте все сами, когда разберетесь в основах ...).
Идея мне понравилась. Кому еще?
ТЗ на оболочку и необходимые результаты прокатит. Формально задачу программисты выполнят. Но это не решит вопрос удобства пользователя. Например насчёт расположения интерфейса, обычно надо просить программиста отладить в ручном режиме, в процессе нескольких сеансов тестирования.
Шутливая тема подняла очень интересный разговор! Автору респект! Ну, господа, вас читать одно удовольствие. Наконец-то мы уходим от политики!
Да, удобство пользователя - одна из "засад", кторую так системно и не решили. Тестировани есть, но оно всё-таки проходит мимо эргономики.
В медицине я не слышал ))
А вот в нашей ИТ отрасли полно подобных примеров: "пришёл, увидел, начал командовать программистами" )))
Про ОСТ. Совсем недавно один довольно большой руководитель ИТ- разработок спросил меня, что такое ЕСКД.
.
Да. Согласен.
Есть две стороны:
Каждая из сторон – это несколько и более человек. Основа непонимания между сторонами – в том, что оно (непонимание) есть и между людьми, относящимися к одной стороне.
Я сожалею, что стал участвовать в дискуссии по, мягко говоря, несостоятельной статье. Вспоминаю, что программа на каком-либо алгоритмическом языке (в 1970-80-е годы) начинались с определения величин, в ней участвующих. А мы обсуждаем статью, в которой не определено кто с кем разговаривает. А сразу идёт речь о языке общения между ними.
Кстати. На запрос «непонимание между заказчиком и программистами» Яндекс выдал 7 млн.результатов. В советские времена каждый автор был обязан сделать следующее:
Содержание п.1-п.4 оформлялось как «Введение». По нему предполагаемый читатель принимал решение, тратить ли ему деньги и время на статью. Если в результате чтения статьи обнаруживалось, что обещание по п.4 оказалось невыполненным, то наказывался и издатель и автор. Издания первого переставали покупать. Статьи второго переставали читать.
Но, в нынешние времена огульной безнаказанности, вышеизложенная практика подавлена мутным потоком плагиатов. К ним относится и обсуждаемая статья, на которую мы напрасно тратим своё время.
Сколько раз - увы - приходилось обсуждать некий загадочный документ под названием "ТЗ" без необходимой расшифровки. Представления о том, что там должно быть написано, редко совпадают, особенно - если заказчик, исполнитель и другие участники ранее не встречались.
Риторический вопрос: все ли представляют себя то, что "ТЗ" - это сокращение от более содержательного "Техническое задание на разработку (проектирование) ...", при этом все детали реализации решения содержатся в других документах (ЭП, ТП, РП. ТРП - в зависимости от используемого стандарта на документирование)? Именно там и должны находится все детали, к примеру, интерфейса пользователя, уже согласованные ранее с заказчиком.
Никаких засад при соблюдении процесса. Нужна эргономика - вы ее получите.
Программисты - профессионалы (другие не нужны), зачем ими командовать? Кто-то командует скрипачами или духовыми в симфоническом оркестре?
Про ОСТ: бывает всякое, опыт работы в отрасли приходит не сразу. Редко, когда кто-то начинает с изучения стандартов, если этого не требуют должностные обязанности. Кстати, автор статьи перечислила несколько книг и важных тем, но не упомянула PMBoK (или любой другой BoK), APM, ISO, CCPM и другие отраслевые источники и концепции.