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

Программист — не гадалка

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

  • сообщить окружение ПО, где возникла проблема: железо, операционная система, браузер, номер сборки, полное наименование клиента (если это у клиента);

  • если вы ещё и анамнез соберёте, цены вам не будет: что делали с ПО, что происходило в момент сбоя, были ли проблемы на инфраструктуре, скриншоты ошибок и т.д.;

  • сообщить о целях и задачах пользователя ПО — возможно все и всех недопоняли.

Излагайте прямо

Если вы внешний или внутренний заказчик, не нужно пытаться написать максимально сложное техническое задание, чтобы отправить или передать его разра��отчику. Назначьте встречу (митинг, совещание, переговорите по Zoom или подойдя к столу) и обговорите свои цели, задачи и требования. Программист сам составит техническое задание и отправит его вам на согласование. Это удобно и правильно, потому что он уже не излагает фантазии, а описывает конкретную функциональность исходя из своих возможностей и набора имеющихся в распоряжении инструментов разработки. Если вы решите самостоятельно писать ТЗ и требовать его досконального исполнения, скорее всего, сроки проекта затянутся (возможно, навсегда).

Не считайте программиста тупым

Конечно, каждый из нас владеет своей профессией и может достигать в ней совершенства. Но совершенно неясно, почему маркетолог или продажник внезапно начинают объяснять программисту задачу, стремясь максимально упростить язык. Например, вместо «нужно собирать контактные данные с формы в разделе покупки, присваивать User ID и подгружать связанные чаты и почту» может прозвучать что-то типа «ну вот клиент заходит что-то купить, нужно его имя-фамилию-телефон, а потом посмотреть чатик и почту, и вот чтобы всё это было вместе, на одной страничке, а ещё нужно его пометить, как будто вот зелёная точка карандашом, красная точка…». Зачем? Вы реально полагаете, что человек, способный написать работающую программу, не способен понять что-то из описаний бизнес-логики? Даже если вдруг ему что-то непонятно, он обязательно уточнит. Чем проще и профессиональнее вы изъясняетесь, тем быстрее найдёте с программистом общий язык.

Не ставьте сроки и условия

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

Не отворачивайтесь от своей же задачи

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

Не приходите с ненужными задачами

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

Не давите властью

Вы коммерческий директор, директор по маркетингу, директор по развитию или продакт менеджер 80 lvl? Не стоит применять начальственное давление и административный ресурс. Это в принципе фиговая мотивация, а для программиста — втройне. Как бы вы ни смотрели на свою должность, в позиции заказчика вы зависите от программиста и вам его не заменит менеджер Маша или секретарь Света. Давление властью может привести лишь к итальянской забастовке, когда программист не будет "по дружбе" рвать жилы и работать ночами над задачей — он встанет и уйдёт ровно в 18:00. Потому что «уважать себя заставил» и плевал на вашу мотивацию. А вот если вы, имея высокую должность, попросите программиста о помощи и облегчите коммуникации по сбору и агрегации требований, считайте, вы обрели надёжного корпоративного друга. Да, впрочем, это касается любых адекватных сотрудников.

Не косите под программиста

Каюсь, грешна: в начале своего карьерного пути мне приходилось формировать 2-3 запроса в неделю на разработку и доработку для очень крутого программиста АСУ. Это был корифей разработки и никак не хотелось ударить в грязь неопытным лицом молодого аналитика. И я стала пытаться описывать нужные запросы на SQL, зная его более чем посредственно. Он получал схематичные ТЗ с кучей ненужных, бессмысленных и, что важно, неправильных кусков кода. Поговорили, посмеялись, наладили работу. За последующие 12 лет я не раз видела такие случаи обращения в ИТ-отдел. И это отчасти смешно, а отчасти очень сильно раздражает разработчиков, потому что там, где вы видите попытку поговорить на одном языке, программист видит исковерканный код и глупость. Никакого нокода, псевдокода и прочих UML-диаграмм, если вы досконально в них не разбираетесь. Универсальнее человеческого языка здесь что-то сложно придумать.

Не переобувайтесь на ходу

1 сентября вы попросили вставить скрипт на страницу сайта, 7 сентября вы попросили разработать форму регистрации, 9 сентября добавился какой-нибудь попап, и вот уже 17 сентября вы просите новый сайт, мобильное приложение и промо-игру для привлечения высокодоходного сегмента аудитории. Вы сбили свои планы, круто изменили масштабы проекта, полностью проигнорировали занятость и рабочие планы разработчика и вообще не молодец. И если для внешних клиентов есть договор с подписанным ТЗ и его расторжение, то для внутреннего клиента может быть ещё и руководитель, который скажет «Ну а что такого, справишься?» Зная это, постарайтесь продумать масштаб проекта заранее и вносите минимальные, важные для текущей постановки задачи, изменения. Это позволит завершить задачи эффективно и без срыва дедлайнов.

Вообще программисты довольно дружелюбные ребята, осознающие свою нужность и готовые браться за задачи, интересные и не очень. Внутри компании или на стороне исполнителя, они выполняют важную функцию: делают желаемое и воображаемое реальным. А уже это реальное делает проще работу внутри компании или команды. Замечательная же функция! В остальном нужно просто быть человеком.

К чему это я? 

С Днём программиста, наши маги кода и волшебники техзаданий, понимающие и объясняющие, молчаливые и не очень, претворяющие в жизнь самые смелые требования и дающие рациональные ответы на экзистенциальный вопрос «А оно вам надо?» Пусть всё будет хорошо.  

Ваш RegionSoft