Хабрахабр

С Днём Программиста! Любите своих разработчиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наш Telegram-канал

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

Если вы из Нижнего Новгорода

Ребята, нестандартная просьба для Хабра — мы в Нижнем Новгороде ищем себе продажника, но как бы продажника ++, ибо во внедренческую компанию. Если у вас есть молодой житель Нижнего Новгорода (увы, только офис), мечтавший войти в ИТ, но не вошедший, киньте, пожалуйста, ссылку на вакансию — у нас классно и после нас человек уходит с шикарным опытом (правда, что-то не уходят, по 10-15 лет работают, и это круто!).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть