Постановка задач в разработке крупного новостного портала

Довелось мне выступить на конференции айтишников и журналистов вместе с моей коллегой журналисткой. Рассказывали мы про взаимодействие между отделом разработки и другими на примере взаимодействия с редакцией. Моя часть рассказа заключалась в том, что я давал советы, как правильно ставить задачи разработчикам, если вы не технарь. Ниже привожу текст выступления их моего черновика подготовки к нему (поскольку из черновика, то иногда там я перескакиваю немного):

Проблемы взаимодействия технарей и гуманитариев свойственны не только IT, но и другим областям и принципы улучшения коммуникации схожи. Самым простым способом является наличие человека, который бы выполнял роль посредника между внутренними заказчиками и разработчиками, так называемого “переводчика”. Этот человек, обладает техническим складом ума, часто техническим образованием или опытом работы на технической позиции, умеет общаться с людьми, находить к ним подход, то есть обладает высокими коммуникативными навыками. Его задача, понять желания обеих сторон, то есть понять, что хочет заказчик и перевести это на язык технической документации или технических терминов, понятных разработчику, и в обратную сторону, суметь объяснить заказчику в понятных для него словах, с какими техническими трудностями столкнулись разработчики или какая тех информация и как влияет на задание заказчика. Обычно это роль выполняет бизнес-аналитик, в его отсутствие тимлид, проектный менеджер или технический редактор

Человек, который бы выполнян такую роль нужен только на первом этапе, пока не будут налажены устойчинвые процессы взаимодействия, после чего необхоимость в нем будет уменьшаться если он не занимается замыканием потоков информации на себя.

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

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

Когда возникла такая необходимость я взял на себя такую роль в нашей компании и рассказываю вам сейчас, что это значит и что может сделать каждый на своем месте, чтобы необходимость в таком человеке не возникала или не была столь острой.

Компания продуктовая, есть основной продукт и связанные, помельче. Росли быстро, в какой то момент стартаперский хаос стал неэффективным и больше не способствовал креативу и быстрому развитию проектов. Первой стала проблема ограниченности ресурсов: работы было много, ресурсы ограничены. Менеджеры, маркетологи, аналитики, редакция и прочие внутренние заказчики стали соревноваться за ресурсы разработки. Стали приоритизировать проекты, планируя ресурсы в жестком ручном режиме. Заказчики стали брать наглостью и просьбами к разработчикам “мимо кассы” в коридоре, скайпе и почте. По итогу все информационные потоки замкнули на пару человек: начальника отдела разработки и меня, чтобы избежать потерь времени и пропихивание незапланированных задач. Разработчики смогли наконец вхдохнуть спокойно, их больше никто не дергал, не отвлекал от задач и не преследовал на кухне. Постепенно эффективные команды менеджер-разработчик стали складываться на отдельных проектах, тогда отпадала необходимость в ручном управлении и посредничестве и процесс отдавался этой связке, оставляя лишь общий периодический контроль и проверку кода. Основной задачей всегда была максимальная эффективность разработчиков. У каждого свой уровень, своя кривая роста и свои предпочтения, куда он хочет двигаться и какие задачи решать. Кто-то мог сам вести задачу с момента идеи, кто-то требовал четкую и детальную постановку и декомпозицию. Моя задача была предоставить максимальные возможности и убрать все преграды. Можно условно разделить все мои задачи на 4 группы:

1. Блокировка. Блокировка плохих или спорных решений, как со стороны разработчика, так и со стороны менеджера. Я обладаю более общей картиной по всем проектам и могу знать, что это уже где-то решено или что решение должно быть более общим и так далее
2. Разблокировка. У разработчика есть вопрос по задаче, который он не может решить сам, или требуется решение человека из другого отдела, например, маркетолога.
3. Перенаправление. Я всегда знаю, кто знает то, что не знаю я.
4. Принятие решений. Зная приоритеты, очередь, трудоемкость и ближайшие планы по проектам, я могу принимать быстрые решения по задачам для разработчиков или могу сказать “нет” тому или иному предложенному функционалу.

Как же наладить взаимодействие заказчиков с разработчиками, когда такого человека еще нет или ваша команда недостаточно большая, чтобы оправдать наличие такого человека?

Для того, чтобы разработчик смог сделать задачу, ему необходимо 4 вещи:

1. понимать, зачем это надо делать и что надо делать
2. уметь это сделать, иметь достаточную компетенцию и квалификацию
3. иметь ресурсы, возможность сделать задачу — т.е время, компьютер и здоровье
4. желание сделать, мотивацию

Если мы не заказчик и руководитель в одном лице, то мы можем влиять только на первый пункт.

Для начала стоит определиться с вопросом “зачем” или “для чего”. Ну например, повысить конверсию, увеличить время проведенное на странице или количество страниц за сессию. Причем не в мифических единицах, типа “больше”, “лучше”, а в конкретных цифрах, желательно достижимых и реальных.

Что обязательно должно быть в задаче:

1) Зачем делать это задание, с точки зрения бизнеса, какой эффект мы ожидаем

2) Что именно надо сделать в задании

здесь стоит отметить, что вам надо сконцентрировать на том “что” надо сделать, а не “как” надо сделать. Это очень важно. Допустим вам надо заставить пользователей присылать вам новости и вы ставите задание “сделать красную кнопку, на которой будет написано “пришлите””. Это плохой вариант, если вы не ux специалист, дизайнер с разработчиком выдадут существенно лучший результат, если вы вместо этого напишете “сделать возможность для пользователя присылать новости, которая будет выделяться на странице”. Вы же не технический специалист, это их работа придумать “как” сделать то, что вам нужно, чтобы достичь своих базнес целей. Вы будете удивлены, насколько часто вам будут предлагать вариант лучше вашего.

3) Критерии выполнения задания или DoD — definition of done. Как понять, что задание выполнено.

В задание добавляется крайний срок, при необходимости.

Другие ошибки постановок.

• НЕ надо писать сделайте как там, но по другому
• слишком общая формулировка. Недостаточно деталей для определения, что надо сделать.
• размытая ответственность. К сожалению иногда люди боятся брать на себя ответственность либо по личным причинам, либо потому что в компании так заведено. В итоге задание превращается в переписку 10 человек, где много шума и мало толку, а лицо, которое может принять решение занято и не отвечает по несколько дней

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

О прерываниях или почему нельзя отвлекать разработчика, когда у вас появилась новая идея. Разработка требует большой сосредоточенности и погружения. Идеальным называется состояние потока, это наибольшая концентрация и наибольшее погружение. Отвлеките человека мелким вопросом и он потратит 15 минут чтобы туда вернуться. Это как когда вы пишете статью и в середине предложения вас кто-то прерывает и спрашивает где ключи от танка. Понятно, что совсем никогда отвлекать вы не можете, иногда все же надо, просто старайтесь делать это по существенным вопросам и как можно реже. Чего точно нельзя делать, так это стоять за плечом разрабтчика и “направлять” его работу.

В идеале, от людей, которые что-то хотят от разработчиков, требуется понимать базовые термины и понятия разработки в этой области. То есть отличать понятия “интерфейс” от “прототип”, а так же более экзотические термины как, например, “wireframe”. Приведу живой пример: редакции в нашей компании необходимо иметь представление о html разметке, блоках и стилях, чтобы эффективно верстать новости, которые не будут ломать страницу и будут выглядеть для пользователя именно так, как они задумали. То есть иметь представление о базовых правилах типографики в интернете, параграфах, обтекании, выделении цитат и тому подобное.

Аналогично в других областях могут быть другие требования и бизнес-правила.

Я сознательно опустил описание человеческих факторов, темперамента, характера, умения работать в команде и так далее, хотя я бы хотел посоветовать почитать книжки по психологии межличностных отношений и освоить хотя бы одну из психологических типологий, например тот же Майерс-Бриггз, чтобы понять, насколько люди разные и насколько разные подходы могут быть.

Объяснить что-то другому человеку, чтобы он вас понял именно так, как вы хотите — часто достаточно сложно. Сложность заключается в ином восприятии слов, картинок, да и вообще действительности, как таковой. Мы рассматриваем частный случай, когда гуманитарий заказчик, в нашем случае это редакция, пытается что-то объяснить и получить результат от технарей разработчиков. Мы не знаем того, чего мы не знаем. Это значит, что мы не знаем того, что мы не знаем о процессе написания кода, равно как и разработчик не знает, что он не знает о написании статей и ведения интернет-сми. Поэтому между разработчиками и гуманитариями появляется человек, который может переводить с языка идей, образов и мыслей, на язык логики и тех. задания. Это может быть бизнес-аналитик или проектный менеджер. Поработав в такой роли, я могу сказать, что в ней нет особой необходимости, если бы одни могли говорить, а вторые слушать. Постановщик задачи часто не пытается четко сформулировать свои желания и ждет, что это сделают за него, подхватят его идею, развернут и расскажут, как надо, а разработчик ждет, что ему предоставят информацию в понятном, недвусмысленном виде, без необходимости что либо прояснять, что все будет просто и понятно. Всем будет намного легче, если первые будут стараться четче формулировать свои желания, а вторые будут задавать вопросы. Истории про кнопку “сделать хорошо” появились не случайно. Очень много проблем возникает, если отсутствуют бизнес процессы, регулирующие контроль над постановкой, исполнением и качеством, а также последующей проверкой достижения целей разработки. В таком случае каждый изобретает свой способ постановки задач, предпочитая удобство выше эффективности.

Стоить отметить, что идеальный уровень бюрократии при постановке задач на разработку очень сильно различается в зависимости от стуктуры компании: аутсорс или продуктовая разработка, величиной команд, которые работают над проектами и так далее.