Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Программист — человек суровый, строгий, умный и отчасти опасный. Именно так ты думаешь, когда погружаешься в ИТ на стороне заказчика, того, кому что-то от программиста надо. И вот уже ты плодишь сущности, путаешься в терминологии и важно раздуваешь щёки, чтобы не показаться каким-то не таким рядом со сверхразумом. Казалось бы, всего-то нужно подобрать ключ к его мыслям и вы уже на одной волне делового, а то и дружеского общения. Но это же почти невозможно? Я побывала по обе роли этой ситуации, поэтому могу смело утверждать: всё проще, чем вы думаете.
Программист — не гадалка
В одной из компании, где приходилось работать, была очень «бесячая» сотрудница: она закидывала мне, тогда инженеру по тестированию, проблему и при этом не озвучивала не только сборку и окружение, но даже не называла клиента, у которого произошёл сбой. Ей вероятно казалось, что у меня под столом магический хрустальный шар. На замечания мне отбривалось однозначное «тебя должна волновать только техническая часть». Так вот — это самый анти изо всех антипаттернов общения с программистами. Вот как нужно сообщать о проблеме программисту (а заодно тестировщику, инженеру и любому другому технарю, который должен вам помочь):
сообщить окружение ПО, где возникла проблема: железо, операционная система, браузер, номер сборки, полное наименование клиента (если это у клиента);
если вы ещё и анамнез соберёте, цены вам не будет: что делали с ПО, что происходило в момент сбоя, были ли проблемы на инфраструктуре, скриншоты ошибок и т.д.;
сообщить о целях и задачах пользователя ПО — возможно все и всех недопоняли.
Излагайте прямо
Если вы внешний или внутренний заказчик, не нужно пытаться написать максимально сложное техническое задание, чтобы отправить или передать его разработчику. Назначьте встречу (митинг, совещание, переговорите по Zoom или подойдя к столу) и обговорите свои цели, задачи и требования. Программист сам составит техническое задание и отправит его вам на согласование. Это удобно и правильно, потому что он уже не излагает фантазии, а описывает конкретную функциональность исходя из своих возможностей и набора имеющихся в распоряжении инструментов разработки. Если вы решите самостоятельно писать ТЗ и требовать его досконального исполнения, скорее всего, сроки проекта затянутся (возможно, навсегда).
Не считайте программиста тупым
Конечно, каждый из нас владеет своей профессией и может достигать в ней совершенства. Но совершенно неясно, почему маркетолог или продажник внезапно начинают объяснять программисту задачу, стремясь максимально упростить язык. Например, вместо «нужно собирать контактные данные с формы в разделе покупки, присваивать User ID и подгружать связанные чаты и почту» может прозвучать что-то типа «ну вот клиент заходит что-то купить, нужно его имя-фамилию-телефон, а потом посмотреть чатик и почту, и вот чтобы всё это было вместе, на одной страничке, а ещё нужно его пометить, как будто вот зелёная точка карандашом, красная точка…». Зачем? Вы реально полагаете, что человек, способный написать работающую программу, не способен понять что-то из описаний бизнес-логики? Даже если вдруг ему что-то непонятно, он обязательно уточнит. Чем проще и профессиональнее вы изъясняетесь, тем быстрее найдёте с программистом общий язык.
Не ставьте сроки и условия
Конечно, любой заказчик имеет видение своих сроков, но это не повод говорить, что всё нужно ещё вчера, — это лишь повод обратиться к разработчику заранее. Работает примерно так: вы рассказываете о содержании задачи, называете желаемые сроки и обозначаете важность задания. Программист оценивает выполнимость, сложность, варианты исполнения, занятость ресурсов и уже отвечает вам, в какие сроки он уложится и с какими потерями. В свою очередь, заказчик имеет полное право попросить исполнения названных разработчиком сроков. И помните: программист никогда не виноват в том, что менеджер не способен адекватно планировать.
Не отворачивайтесь от своей же задачи
Если вы полагаете, что на передаче технического задания ваша ИТ-история закончилась, то вы ошибаетесь. Вы заказчик, у вас требования и именно вы должны оценить проект, а именно протестировать его на промежуточных этапах и в финале, попробовать проект на реальных рабочих средах, попросить своих коллег и подчинённых оценить работоспособность и актуальность релиза, проекта, функции, фичи и т.д. Программисты всегда высоко ценят помощь заказчика и ратуют за вовлечённость (без указаний, что и как делать), потому что такой подход облегчает разработку и тестирование, помогает двигаться от этапа к этапу быстрее.
Не приходите с ненужными задачами
Перед тем, как обратиться за разработкой к внешнему или к внутреннему разработчику, проверьте, действительно ли вам так нужна фича, функция, сайт, лендинг и т.д. Потому что нет ничего обиднее, когда ты реализуешь задачу, тестируешь, сдаёшь, а в итоге ею никто не пользуется. Как правило, внутренние разработчики активно собирают обратную связь, чтобы понять, насколько полезны и эффективны их человеко-часы, — и если в результате опроса выясняется, что сделанное не используется, мотивация значительно падает. Ну а если на разработку ещё и выделены инвестиции, то вывод напрашивается сам собой: кто-то не умеет продумывать и мотивировать свои запросы.
Не давите властью
Вы коммерческий директор, директор по маркетингу, директор по развитию или продакт менеджер 80 lvl? Не стоит применять начальственное давление и административный ресурс. Это в принципе фиговая мотивация, а для программиста — втройне. Как бы вы ни смотрели на свою должность, в позиции заказчика вы зависите от программиста и вам его не заменит менеджер Маша или секретарь Света. Давление властью может привести лишь к итальянской забастовке, когда программист не будет "по дружбе" рвать жилы и работать ночами над задачей — он встанет и уйдёт ровно в 18:00. Потому что «уважать себя заставил» и плевал на вашу мотивацию. А вот если вы, имея высокую должность, попросите программиста о помощи и облегчите коммуникации по сбору и агрегации требований, считайте, вы обрели надёжного корпоративного друга. Да, впрочем, это касается любых адекватных сотрудников.
Не косите под программиста
Каюсь, грешна: в начале своего карьерного пути мне приходилось формировать 2-3 запроса в неделю на разработку и доработку для очень крутого программиста АСУ. Это был корифей разработки и никак не хотелось ударить в грязь неопытным лицом молодого аналитика. И я стала пытаться описывать нужные запросы на SQL, зная его более чем посредственно. Он получал схематичные ТЗ с кучей ненужных, бессмысленных и, что важно, неправильных кусков кода. Поговорили, посмеялись, наладили работу. За последующие 12 лет я не раз видела такие случаи обращения в ИТ-отдел. И это отчасти смешно, а отчасти очень сильно раздражает разработчиков, потому что там, где вы видите попытку поговорить на одном языке, программист видит исковерканный код и глупость. Никакого нокода, псевдокода и прочих UML-диаграмм, если вы досконально в них не разбираетесь. Универсальнее человеческого языка здесь что-то сложно придумать.
Не переобувайтесь на ходу
1 сентября вы попросили вставить скрипт на страницу сайта, 7 сентября вы попросили разработать форму регистрации, 9 сентября добавился какой-нибудь попап, и вот уже 17 сентября вы просите новый сайт, мобильное приложение и промо-игру для привлечения высокодоходного сегмента аудитории. Вы сбили свои планы, круто изменили масштабы проекта, полностью проигнорировали занятость и рабочие планы разработчика и вообще не молодец. И если для внешних клиентов есть договор с подписанным ТЗ и его расторжение, то для внутреннего клиента может быть ещё и руководитель, который скажет «Ну а что такого, справишься?» Зная это, постарайтесь продумать масштаб проекта заранее и вносите минимальные, важные для текущей постановки задачи, изменения. Это позволит завершить задачи эффективно и без срыва дедлайнов.
Вообще программисты довольно дружелюбные ребята, осознающие свою нужность и готовые браться за задачи, интересные и не очень. Внутри компании или на стороне исполнителя, они выполняют важную функцию: делают желаемое и воображаемое реальным. А уже это реальное делает проще работу внутри компании или команды. Замечательная же функция! В остальном нужно просто быть человеком.
К чему это я?
С Днём программиста, наши маги кода и волшебники техзаданий, понимающие и объясняющие, молчаливые и не очень, претворяющие в жизнь самые смелые требования и дающие рациональные ответы на экзистенциальный вопрос «А оно вам надо?» Пусть всё будет хорошо.
Ваш RegionSoft
