Сегодня день программиста, 256-й день в году. И мы решили написать пост не для наших коллег-разработчиков, а для тех, кто рядом с ними и с нами. Для тех, кто доводит нас до белого каления, заставляет закипать мозг, выпускать пар и нервно рассказывать о сущностях, интерфейсе и причинах сорванного дедлайна. Для вас, дорогие менеджеры, коммерсы, аналитики, руководители без ИТ-бэкграунда и прочие офисные друзья.

Если вы читаете Хабр, то скорее всего, вам приходится общаться с программистами, просить у них допилить фронтенд или бэкенд сайта, изменить код аналитики, повесить очередной фрагмент кода в шапку сайта, сделать доработки ПО для клиента и многое другое. Так как найти общий язык с разработчиком, чтобы не поссориться? Мы кое-что знаем об этом.

Итак, сразу списком.

Чётко формулируйте свои требования. Всегда: неважно, просите ли вы сделать крошечную выборку из базы данных или готовите серьёзный программный проект для клиента. Не существует описания задач в виде «Сделай мне карточку события как профиль ВКонтакте» (ВКонтакте работает очень много программистов, найми столько же и сделаем), «Ну вот ты сделай всё, а я выберу» (сделать несколько вариантов программы — дело дорогое, тебе СЕО согласовал?), «Давай сделаем вот такой шарик» (это риббон и для его внедрения нужны специальные библиотеки). Прежде всего, вы должны понимать, что хотите получить, и именно это нужно транслировать программисту. Формулируйте требования русским языком, без канцелярита и псевдо технических высказываний — и да, желательно письменно.

Кстати, о письменности. Это величайшее изобретение за всю историю человечества, в наше время оптимизированное компьютером. Не стесняйтесь использовать бумагу в разговоре с разработчиком:

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

Если вам это кажется какой-то сложной наукой, погуглите, чем занимается системный аналитик и что он использует в своей работе — очень многое можно взять на вооружение.

Не нужно использовать UML-диаграммы, блок-схемы и псевдокод, если вы ими не владеете. На пути попадался не один менеджер, который был очарован UML-диаграммами и рисовал в них всё, что ему было нужно: от плана совещания до описания маркетинговой акции. И правда, инструмент кажется логичным и удобным, однако — сюрприз — UML был создан для проектирования архитектуры ПО и каждое обозначение это не просто стрелочка или кружочек, а весьма осмысленный компонент. К тому же, ваш программист может не знать UML и для него это будут совершенно бессмысленные блоки.

Та же история с блок-схемами, в которых разные формы блоков существуют не для красоты, и с псевдокодом. Не надо писать в стиле: «ЕСЛИ месяц = апрель, ТО табличка с данными поле 1 поле 2 поле 3». Это просто нечитабельная ерунда, которая не покорит ИТ-службу, а в лучшем случае рассмешит.

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

И ещё — если вас попросили посмотреть, что получилось, оценить прототип или протестировать функциональность на предмет того, соответствует ли она вашим требованиям, не идите к десяти соседним сотрудникам и не делайте это вместе. Так вы значительно увеличиваете время до завершения финальной версии.



Рубрика «Их нравы». Сравним аналогичные запросы на русском и английском языках. Работа, любовь, деньги — всё как у всех. Но главное, как они видят пользователей?

Не обвиняйте разработчиков во всех проблемах. «ИТ-служба так долго работала над кодом», «Айтишники что-то дедлайн проминают», «Что-то программист так долго копался в ТЗ» — знакомо, да? Легко свалить проблему на человека, который взаимодействует с техникой, — ну там же точно что-то могло заглючить. Нет, ведите строгий учёт времени, фиксируйте факт передачи задач (можно это делать, например, в CRM или на диаграмме Гантта), пусть каждый отвечает только за свою работу.

Ещё одна крайность — в случае недовольства заказчика посыпать голову пеплом и кричать: «Что ты там такое накодил! Завожу критикал и перевожу на тебя! Мы теряем деньги и репутацию! Срочно!» Паника легко подхватывается коллегами и руководством, нервы программиста на пределе. А на поверку выходит, что у клиента отвалился порт или упала скорость соединения. Учитесь не винить, а спрашивать: «Вась, ООО «Волга» обратилось с проблемой: нет подключения к базе. Не подскажешь, что там может быть, куда копать?» Чувствуете разницу?

Не тяните в рабочий проект идеи со всего мира. Google добавил фильтры в поиск, Яндекс включил Алису, Хабр запустил новую мобильную версию, Salesforce включил искусственный интеллект, RegionSoft выпустил CRM v.7 и вот вы уже несётесь по коридору с тем, чтобы предложить внедрить эти технологии в проект вашей компании, ведь так поступают ИТ-гиганты. Однако любые изменения должны внедряться с точки зрения целесообразности, востребованности и окупаемости. И если улучшения не принесут пользу конечному пользователю и не приведут к получению прибыли, их внедрение станет лишней нагрузкой разработчика. Подготовьте обоснование, расчёты, посчитайте себестоимость внедрения фичи и только после этого принимайте решение о начале обсуждения вопроса.

Не оценивайте сложность работы программиста, если вы не тимлид. «Нужен модуль расчёта объёма коробки под отправку посылки, тут делов-то на полдня, давай засядь!» — оптимистично взывает маркетолог Маша и мчится пить чай перед третьим совещанием. При этом самой Маше неизвестно, откуда она взяла такую норму времени. У программиста существуют рабочие задачи, текущие вопросы, над ним висит багтрекер и сбоку подмигивает бэклог, соответственно именно между ними он будет искать время на решение задачи. И не факт, что задача, решаемая в 15 строчек кода, может быть решена за время набора этих строчек — время отнимает выбор алгоритма, поиск решения, подбор библиотек, отладка кода, автотесты и т.д.

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



Не старайтесь влиять на стек технологий разработки, если вы сами ничего не разрабатываете. Ситуация банальная: менеджер едет на очередную межгалактическую ИТ-конференцию, слушает доклады и его мозг внезапно отсекает, что везде шум вокруг языка Go, а тут ему ещё и плюшевого Гофера подарили. И вот он стоит перед ИТ-департаментом, гладит обретённого суслика и рассказывает об услышанных преимуществах Go и о том, как его в нашем кровавом энтерпрайзе применить.

Ответ прост. Программисты — ребята крайне любознательные и узнают о языках программирования, СУБД, новых операционках, библиотеках и фреймворках гораздо раньше, чем про них пишет свой доклад очередной участник конференции. При этом они не просто любопытствуют, а смотрят, сможет ли сгодиться та или иная технология для облегчения труда и укрепления веры в продукт (потому что программисты ещё и крайне ленивые в хорошем смысле этого слова). Поэтому именно им решать, что тащить в стек разработки, а что пусть отлежится до лучших времён и новых задач. И вы их в этом вряд ли переплюнете.

Осторожно относитесь к письменной речи, она не передаёт интонацию (впрочем, это относится ко всем коллегам и вообще окружающим). Если вы напишете «А сделай мне выгрузку за час)))))))))))))))» или «Я бы это лучше реализовал, мне кажется, тормозит))))))))))))», скобочки вас не спасут — будет считан именно главный посыл. Любые рабочие вопросы описывайте чётко и безэмоционально. Если вам понравилась работа, можете подарить шоколадку :-)



После запроса «why are russian programmers so good» ушли гордиться

Не навязывайте свои способы общения. Сегодня у каждого из нас на рабочем ПК и на мобильнике с десяток средств коммуникации: Telegram, Skype, СМС, телефон, Viber, почта, Slack, Jira… И каждый из них имеет свой круг задач и абонентов. Поэтому, если программист просит в выходные писать только в телегу, задачи ставить только в Jira, а звонить только по Skype, у него на это есть веские основания: он точно знает, что не забудет выполнить работу, связанную с этими контактами. А вот ваша СМС «Запусти в понедельник отчёт по платежам за первое полугодие» затеряется в тредах обсуждения воскресного похода. Поэтому лучше писать об этом в рабочих программах и не считать себя исключительным и самым оперативным в общении и постановке задач. Поверьте, это несложно.

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





У отечественного Яндекса совсем другой взгляд на вещи: даже Ада Лавлейс причислена к программистам 1С, а в топе вакансий Assembler и Delphi (если что, мы искали в анонимном браузере). Но главное, что есть 256 день — и он сегодня :-)

Учитесь у программистов и учите терминологию. Человек, умеющий программировать, системно и логически мыслит, умеет расставлять приоритеты, видит суть вещей и отлично знает предмет (не, ну в честь праздника-то можно немного преувеличить!). У него есть чему поучиться — тем более, раз вы работаете в ИТ-сфере, вам нужно достойное владение понятийным аппаратом и профессиональной лексикой. Общайтесь по работе, уточняйте спорные моменты, расспрашивайте, запоминайте термины и их определения — это точно не помешает вашей карьере. А вот взаимопонимание с программистом станет определённо лучше.

По крайней мере, вы не напишете на корпоративном портале «С Днём программиста всех причастных»!, а сможете составить примерно такой текст:

«Ребята! С Днём программиста! Как здорово, что есть вы, которые вовремя коммитят код, проводят рефакторинг и делают наше ПО ещё быстрее и интуитивнее, вовремя собирают билды и запускают их в продакшн. Желаю вам успешных коммитов, надёжных библиотек, удобных фреймворков и нас, адекватных юзеров. Вы делаете мир настоящего немного будущим. И мы вас любим!»

Ну что, усвоили наш небольшой урок? А теперь пишите поздравление вашим разработчикам.

С праздником, друзья! Команда RegionSoft Developer Studio, разработчики мощной CRM и другого софта для бизнеса, знающие толк в общении между юзерами и программерами

---

Наш Telegram-канал

Передаём привет главному нижегородскому каналу о событиях в ИТ  и их же сайту it52.info. Ходите на ивенты, будьте в теме.