Программисты — молодцы. Они делают важные вещи, оживляют сайты и базы данных, помогают бизнесу и вообще всячески стараются. Раньше все хотели быть космонавтами, сейчас все хотят быть программистами — это логично, ведь отовсюду рассказывают, как легко и просто можно зарабатывать по 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. Недаром все больше менеджеров, дизайнеров и маркетологов изучают верстку и программирование — способность говорить на одном языке с программистами и понятно доносить задачу позволяет быстрее запускать любые проекты и делать это качественно.
Теперь ваша очередь — расскажите в комментариях, как вам удается общаться с программистами, чем они бесят и чем радуют, и чего ни в коем случае нельзя делать, чтобы работать с ними в одной команде долго и счастливо.
Читайте также:
"Программирование" - оно сильно разрослось. в наши 80-е "тыжпрограммист" мог самостоятельно спаять РК-86/спектрум/Спеца, залить туда монитор, интерпретатор (чаще всего бейсика), и писать-отлаживать... сейчас программист не только не знает железа - он зачастую знает только часть операционной системы (одной из), а может и не знать ОС вообще. Не говоря уж о том, чтоб поставить на комп операционку, настроить сеть - эт остало делом отдельной профессии - системных администраторов. (попутно появились профессии администраторов БД, специалистов по ИБ, специалистов по дизайну и даже по поведению. Тестировщики тоже выделись в отдельную профессию).
То, что делал Владимир Зонзов, ("строил модели и составлял для них программы") называя программированием - сейчас это обычные "текущие расчеты на коленке", которые какой-нибудь менеджер по закупу пишет в екзеле десяток за день, или конструктор/прочнист в CADе тоже...
все эти упомянутые Зонзовым книжки Дейкстры и Ван Тассела - ну, они во-первых изрядно устарели, а во-вторых, сказанное там - то, что когда-то было чуть не открытием, сменой мировоззрения и все такое - первокурсникам дают с самого начала. Даже в колледжах (гибридах техникумов и пту).
Задача тестирования - это не задача "удобства пользователя". Задача тестирования - правильное поведение программы. чтобы всем входным данным либо соотвествовали правильные выходные, либо внятный отказ в выполнении.
Удобство пользователя - это UI/UX (заметьте, даже интерфейс - разделили на собственно дизайн (чтоб понятно, красиво, глаз не боялся), и удобство (чтоб руки после работы не отваливались))
Пуководитель ИТ-разработок и не обязан знать что такое ЕСКД. Он работает с ЕСПД:
https://ru.wikipedia.org/wiki/%D0%95%D0%B4%D0%B8%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B9_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D1%86%D0%B8%D0%B8
Это про геометрию 6-8 класс? Замечательный учебник. Я учился по нему.
А его "Элементы теории функций и функционального анализа", в соавторстве с Фоминым - лучшее, что я прочитал в студенческие годы, если не считать "Лекции об икосаэдре..." Ф. Клейна.
При всем уважении.
Абсолютно согласна. Каждый разработчик программного продукта должен изучить предметную область, которую собираешься автоматизировать, до тонкостей. Я всегда повторяю своим сотрудникам, если спрашиваешь у заказчиков "а так может быть", а они отвечают "иногда, да это пустяки" значит будут большие проблемы при тестировании, а еще хуже при активной работе.
С програмистами нужно говорить на языке Вашей предметной деятельности, даже если вы уже изучали программирование в институте, или даже программировали. Очень хорошо, если Заказчик может представить описание бизнес-процессов как есть и как он видить их в будущем и обсудить их архитектором проекта. Это прописные истины, но на моем опыте работы инжнером- электронщиком, программистом, руководителем проектов с 1973 года, после окончания радиофака УПИ я в этом убеждена.
в одиночку посрамили Америку ))). А на самом деле у нас обученных сертифицированных PMP меньше чем, скажем, в Египте. Пару слов по сути
standard - стандарт общего применения. объяснение принципов и понятий. PMBoK. Среди наших ГОСТов конечно есть и такие.
regulation - обязательный (или настойчиво рекомендуемый) к применению документ. PRINCE2 - это к госам в той же Англии, хотя не 100% обязательный.
У нас рекомендательный порядок использования стандартов (я согласен с Вами) ввели преждевременно. Но есть "но" - стандарты устарели. Сейчас, ГОСТ 34 заставляет меня писать требования к программному обеспечению на уровне функций (п.3.4), а программистам намного лучше видеть описание в форме features & user stories. ГОСТ не запрещает - можно просто детализировать функциональные требования в приложениях или дальше на стадии эскизного проекта... "Но" - зачем такой убогий ГОСТ, почему он по сути остался на уровне технологий 70х годов?
Да, и еще... На вопрос "как разговаривать с программистами" я бы добавил - "по английски". Математики и программисты обязаны знать английский, все операторы в языках программирования - на английском.
Ну это шутка конечно - ответ на сложный вопрос "одним словом" )
"Структурное" программирование, функциональное - это в лучшем случае до конца 80х было трендом (я помню это время, тогда я работал с кодом). Нормативные требования, которые остались от совка (и без которых нельзя сдать проект госзаказчику... да и вообще всегда полезно дружить с нормативкой, чтобы не скатиться до спора о базовых понятиях) не учитывают произошедших с той поры изменений.
Т.е. да - я за нормативку. Только чур не путать нормативку с методологией ))). И вот еще что - даже в конкретном ТЗ, расписывая очень формальные требования, нужно понимать, когда нужно остановиться в детализации задания - а иначе Вам самим будет легче написать код ))
1. 34-й ГОСТ не такой уж и убогий, а поскольку он, как и другие ГОСТы, носит рекомендательный характер (после принятия 184-ФЗ), ничего не мешает оговаривать с заказчиком что ТЗ будет написано не "в соответствии", а "на основе" ГОСТ 34.602-89.
2. "... остался на уровне технологий 70-х..." этот ГОСТ по двум причинам:
а) все хотят писать код, но никто не хочет написать стандарт (а это очень непросто), критиковать плохой ГОСТ гораздо проще, чем написать хороший;
б) "ГОСТ на сталь поменять??!! Да я лучше всю жизнь нестриженым ходить буду, чем это дело затевать!" (С) А. Райкин.
P.S. В исходной статье не рассматривается "нулевой" пункт проблем программиста: "Коммерсант продал проект "сделаем за три копейки и за три дня". В одной ИТ-компании после выявления такой проблемы из-за премирования продавцов от оборота, а не от прибыли, уволился коммерческий директор, а программисты вздохнули наконец. Закончилась гонка и заключение договоров на разработку/доработку без учета реальных сроков.
Уважаемый Илья,
лучшая шутка по теме статьи написана Алексеем Березиным.
Статья полна банальностей, обсмеянных еще во времена оны (лет пятнадцать назад как минимум) в том самом эпическом полотне, которое послужило основой материала. Некоторые советы из арсенала "станьте ёжиками" вызывают зубную боль.
Вот как этот:
"Корректное и полное техническое задание. Если речь о сайте — можно сделать прототип страницы, блока или элемента, чтобы показать его разработке. Для создания прототипов пригодятся навыки работы в графическом редакторе, например, Photoshop или Figma, и базовой верстки на HTML и CSS."
Чучхе, короче говоря...
Уважаемый Виталий,
сколько я помню, ГОСТ определял нижнюю планку уровня работ/параметров продукции. То есть нельзя было делать хуже. А вот лучше - было можно.
С другой стороны, разве проблема плохого/устаревшего стандарта - уникальная российская проблема? Сдается мне, что где-то она уже решена. Может пора оглянуться, вдруг велосипед уже изобрели.