Программисты — молодцы. Они делают важные вещи, оживляют сайты и базы данных, помогают бизнесу и вообще всячески стараются. Раньше все хотели быть космонавтами, сейчас все хотят быть программистами — это логично, ведь отовсюду рассказывают, как легко и просто можно зарабатывать по 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. Недаром все больше менеджеров, дизайнеров и маркетологов изучают верстку и программирование — способность говорить на одном языке с программистами и понятно доносить задачу позволяет быстрее запускать любые проекты и делать это качественно.
Теперь ваша очередь — расскажите в комментариях, как вам удается общаться с программистами, чем они бесят и чем радуют, и чего ни в коем случае нельзя делать, чтобы работать с ними в одной команде долго и счастливо.
Читайте также:
Ну что Вы, Михаил! ЕСКД - это ГОСТ 2-й серии, это основа всех конструкторских документов, включая строительных (СПДС)и технологических (ЕСТД), а из него уже вытекает ГОСТ 19(ЕСПД) и 34 (автоматизированные системы, иногда называют КСАС). Очевидно Вы имели в виду достаточность 19 ГОСТа для разработки отдельного программного обеспечения. Это так. Но вы всё равно никуда не денетесь от ГСИ, от СИБИД. Или просто надо не упоминать ГОСТ.
И почему-то Вы свели мои рассуждения к тезису "тестирование - задача удобства пользователя". Это совершенно не моя тз.
ГОСТ не запрещает добавлять новые разделы, новые документы. Просто хуже и меньше нельзя. :))
Что-то устарело, но вот отменили РД-50 и что? Руководители проектов всё равно его используют. Удобно!
Ввели новые условия применения электронных документов. Так оказалось, что слишком "тонко" для типичного программиста, не готовы, не хотят, на бумаге проще. Даже президенту страны пришлось сказать пару слов.
ГОСТ не убогий, просто он расчитан на среднего. Это некий "эскадренный ход", то есть максимальный ход для самого медленного корабля. Если вам не нужен формуляр, то используйте паспорт, не нужен паспорт, используйте этикетку. В чём проблема-то?
В вечном сумбуре любого документооборота на удивление ГОСТ позволяет держать хоть какой-то порядок в разработке. )))
Да конечно! Но это было до вступления в силу 184-ФЗ.
А сейчас "можно делать хуже", так как все ГОСТы стали рекомендуемыми, только ТР - обязательными (если иное не прописано в Договоре и ТЗ на тендер).
Может потому что и принят он был в 1978 году, как и большинство ГОСТов априори.
У меня для вас тут совершенно противоположные новости: Я хорошо знаю закон об "Техническом регулирование". От того что обязательные устаревшие ГОСТы стали регламентами или "Техническими Условиями" (при чем даже без переиздания!) - не сильно и картина поменялась. В конце 1990-х (1998-1999-й года) и уже в начале 2000-х для тех кто продвигал в машины "пропан-бутан" (он же "газ" или в современной терминологии СНГ, Сжиженный Нефтяной Газ) прошли через "огонь, воду и медные трубы", чтобы создать первые станции по переводу машин на газ и первую в Омске при СибАДИ лабораторию для сертификации "измений в конструкцию транспортных средств" с последующими официальным оформлением в техпаспорте автомобиля. Однако, уже после из-за недоработки самих процедур сертификации и чрезмерной сложности оформления, все забивали на это такой толстый болт 32-го диаметра, что ставили с минимальным набором документов (опломбированный и поверенный газовый балон, опломбированный манометр, проверенный и настроенный газовый редуктор и подстройки по зажиганию). И так нормально и весело ездили, вплоть до 2015-го года, спасибо В.В.П. за это, пока минтранс вдруг не ёкнуло в левой пятке и они спустили всех своих "собак" в погоню за "автомобилями с несертифицированными измениями в конструкцию". А то что те кто их ставят, как правило ездят значительно аккуратней молодёжи - так им правая пятка сказать не лишилась. И при этом эти, откровенно говоря мудаки, не предложили ни нормальной доступной процедуры сертификации, ни достаточного количества аккредетированных лабораторий (извините, уважаемые директора, но абсолютное большинство сертификаций для автотранспорта можно получить на любой нормальной СТО), да ещё замкнули всё на парочке МРЭО, об которых ускасались все нормальные водители! И как итог уже на какой болт водители накрутили ментов в этот раз - я думаю говорить не нужно.
Да я знаю этот закон! Даже слишком хорошо. И на этом тему ГОСТов считаю для себя оконченной.
Если уж ссылаться на аналогию со строительством, то описанные проблемы возникают при найме бригады таджиков.
Если нужно построить здание, а не курятник, то нужно пригласить архитектора и долго с ним рассматривать варианты, чтобы заказчик и профессионал одинаково понимали конечную цель. И потом уже архитектор руководит инженерами, которые проектируют и рассчитывают все системы. Определяют, что будет закупаться готовым, а что в виде материалов. Потом архитектор наймет прораба, который будет руководить стройкой. А тот уже будет нанимать рабочих и следить за тем, чтобы было построено то, что запроектировано и в срок.
Почему так очень редко делают заказчики ПО? Как и в строительстве, это дорого. И всегда найдется бригада шабашников, которая скажет "мы это сттто раз делали, сейчас сбацаем".
Отрасль ИТ по структуре очень похожа на строительную. Только почему-то всех, кто в ней работают чехом именуют программистами.
И всё-таки это не так. ГОСТ Р 2.105 - 2019, вступил в силу с 1.07.2020, СИБИД - 2018, ГСИ - последняя редакция 2008, 21.1101 -2013. Старых "ЕСКДшных" стандартов очень мало, они крайне незначительны. Сейчас я пишу исключительно про область ИТ.
Но я полностью солидарен с Вами по поводу стратегии использования всего комплекса стандартов, их развития. Ежемесячно появляется несколько десятков новых ГОСТов и ПНСТ.
Мне особенно понравился раздел 5.2. Вы же прекрасно понимаете, что документы нужно читать с карандашом в руках. Если ещё это можно понять:
"5.2.2 Текст документа должен быть кратким, четким и не допускать различных толкований." (Ок. Последний пункт трактуется в меру собственной совести, всё таки академическая речь требует соблюдения чёткой терминологии)
Но то что творится дальше, и особенно здесь:
"5.2.3 В тексте документа не допускается применять:
- обороты разговорной речи, техницизмы, профессионализмы;
- для одного и того же понятия различные научно-технические термины, близкие по смыслу (синонимы), а также иностранные слова и термины при наличии равнозначных слов и терминов в русском языке;
- произвольные словообразования;
- сокращения слов, кроме установленных правилами русской орфографии, соответствующими стандартами, а также в данном документе;
- сокращать обозначения единиц физических величин, если они употребляются без цифр, за исключением единиц физических величин в головках и боковиках таблиц и в расшифровках буквенных обозначений, входящих в формулы и рисунки."
Это что за комитет по этике?! Вот тут я очень очень рад, что у нас в стране все эти "формулировки" трактуют и используют с таким произволием совести, что любой немец бы разрыдался.
И это ещё не самое худшее. Вот эту 11-ю редакцию новояза уже никаким умом понять нельзя:
"5.2.4 В тексте документа, за исключением формул, таблиц и рисунков, не допускается применять:
- математический знак "-" перед отрицательными значениями величин (следует писать слово "минус");
- знак "
" для обозначения диаметра (следует писать слово "диаметр"). При указании размера или предельных отклонений диаметра на чертежах, помещенных в тексте документа, перед размерным числом следует писать знак "
";
- математические знаки величин без числовых значений, например > (больше), < (меньше), = (равно),
(больше или равно), 
(меньше или равно), 
(не равно), а также знаки № (номер), % (процент);
- индексы стандартов, технических условий и других документов без регистрационного номера."
Извините, а что курили академики, которые писали это? Ну явно что-то сильнодействующие. Я не знаток в наркологии, может кто знает.
А последнее кто-нибудь вообще понять может:
"5.2.6 Документы, включая документ, к которому выпускаются приложения, комплектуют в альбом с составлением к нему описи альбома. Описи присваивают обозначение изделия, для которого разработан основной документ, и код ОП."
Я знаю как выглядит этот альбом. Титульник, заглавный лист, пояснительная записка, чертежи, бланк деталей (спецификация). Может кто-нибудь объяснить мне по человечески вот этот параграф?
Уж не знаю, как много вы используете из этого "регламента", но когда трактуются такие формулировки - как минимум понятие регламент в таком случае оскорбительно в отношению ко всему научно-инженерному сообществу.
Вот из-за таких ай-ти-мнений к консультантам относятся скептически.
Справедливости ради могу сказать, что там есть нормальные разделы и положения, так сказать для людей. Но когда регламенты и стандарты придумываются с потолка лишь бы обосновать пачку денег на столе инспектора или 300 грамм коньяка в его бакале, то я не могу найти приличных слов, чтобы это комментировать.
Анатолий, я же читал зарубежную техническую документацию, она в 10 раз меньше, чем наша. И там нет требований к "однозначности трактовки", люди сами и без них знают как это трактовать, для этого и существуют термины.