Как правильно работать с программистами, управлять IT проектами и ставить задачи персоналу

Добрый день коллеги Меня зовут Николай хлебинский вы находитесь на канале экшн-план в этом видео хочу рассказать о моём опыте построения работы с программистами с разработчиками с инженерами знакомый вам такая ситуация когда вы приходите к программистам с

какой-то задачей Говорите Я хочу сделать вот такую штуку они говорят вам или то что это сделать Невозможно или то что Это займёт очень много месяцев или то что сейчас очень много другой работы и к вашей задаче приступить в принципе они не могут и вы не понимаете как с этим быть что делать для того чтобы решать свои бизнес задачи с их помощью вот в таком случае вот в этом видео хочу рассказать как я подходил к решению Такой проблемы Это довольно типичная чтобы начать о ней разговор Хочу привести один пример из жизни и устроить такой небольшой интерактив вот

смотрите есть у вас такая задача допустим вы сделали сайт и на этом сайте продаются какие-то товары и на карточке каждого товара можно оставить отзыв вот есть такое поле куда можно написать текст и оставить отзыв который появится где-то внизу этой странички так вот что я вас сейчас попрошу сделать поставьте это видео на паузу и напишите в комментарии к этому видео ответ на вопрос Сколько времени по вашему у программиста должно занять решение задачи которые описана вот здесь на экране представим что мы хотим ограничить размер отзыва о том что у нас на этой страничке продается 140 символами потому что возможно в будущем захотим отправлять эти отзывы по СМС клиентам допустим который посмотрели этот товар но не решились еще его купить сейчас Попробуйте оценить Сколько времени должно уйти на решение этой задачи поставить видео и написать в комментарии ваш ответ я естественно дальше расскажу что я на этот счет думаю по моему опыту сколько бы раз вопрос я этот не задавал большинство из отвечающих те кто Не связан с программированием у кого не было опыта разработки отвечают на этот вопрос очень так занижена когда приводит свою оценку час день два дня 15 минут вообще нисколько не надо за три секунды можно сделать это выглядит для того кто никогда не пробовал писать код очень просто на самом деле это не так это совсем не просто когда вы работаете над разработкой над развитием хорошей

информационной системой хорошего программного обеспечения хорошего продукта маленьких изменений в продукте не бывает об этом нужно помнить Почему так Потому что вот эти вот две строчки два предложения в которых менед как правило описывают задачки программистом не хватает ответов на бесконечное количество вопросов Что будет если длина этого отзыва больше 140 символов мы обрежем строку или покажем пользователю который написал или пытается Написать сообщение об ошибке где будет это сообщение об ошибке С каким текстом кто придумает этот текст а как это сообщение будет выглядеть А какой будет класс каскадной системы стилей у такой ошибки Он уже есть или его еще нет обрабатывать ошибку будем на клиенте на сервере А кто Напишет клиентское обрабатывание JavaScript кто будет делать вёрстку Кто будет поддерживать совместимость этого Java скрипта и так далее и так далее этих вопросов очень много соглашаться на расширение функциональности очень просто а кодить новые фичи в продукте сложно поддерживать потом еще дороже и что получается нас в жизни неопытные менеджеры при вот с такими вот короткими формулировками задач которые на самом деле представляют у себя только верхушку айсберга по проектным документациям по требованию к тому что на самом деле надо сделать отдают их программисту программист хороший программист додумывает все оставшиеся вопросы вот которые я приводил в примере самостоятельно отдает результат менеджеру который заказывал с расширением функциональности менеджер на это смотрит у так вот это вот все что было скрыто под водой это же совсем не то что я ожидал сделай-ка Вот это внеси вот такую правку в этот момент из всех остальных подразделений компании все остальные бизнес заказчики присылают такого же качества требования к программисту который отдает результат который потом Возвращается на доработку с такими же некачественными запросами на доработку где ему дальше приходит приходится додумывать когда ему вернули задача на доработку другие бизнес заказчики Поставили ему еще новые задачи все это Копится как Снежный ком никогда не доделывается до конца и в итоге приводит к тому что it команда в компании парализовано сроки на задачи выдаются очень-очень завышенные и нереалистичные и протолкнуть какую-то доработку может только тот кто получает в компании больше всех денег потому что он может Все остальное отодвинуть и какую-то свою задачку пропихнуть так как ему нужно Знакомая ситуация Давайте разбираться Как сделать так чтобы ее

решить Ну и самое главное чтобы в неё в будущем не попадать Я видел ее бесконечное количество раз за последние 10 лет и в какой-то степени научился передавать знания о том как же сделать так чтобы в эту ситуацию не попасть строим процесс it разработки вот этот процесс начинается с гипотезы гипотеза это какой-то запрос наращивание функциональности но выстроенный правильно не Сделай мне товарищ программист вот такую штуку А если мы сделаем вот такую штуку то что-то изменится в ту сторону в которую мы ожидаем причем это изменение должно быть измеримо гипотезы берутся при исследовании рынка при посещении отраслевых мероприятий при общении с клиентами при интервью экспертов которые находятся на вашей стороне при использовании инструментов различных аналитических и по анализу вашей платформы и по анализу других сайтов других площадок других приложений как правило недостатка в гипотез в гипотезах никакой бизнес не испытывает всегда есть люди которые драят наращивание функциональности которые имеют некоторые свое мнение куда надо вести изменения в приложении в сайте в продукте для того чтобы жизнь клиентов наладилась жизнь сотрудников наладилась и так далее что эти люди как правило забывают им приходит в голову какая-то идея они на эту идею надевают розовые очки и считают что эта идея изменит мир к лучшему и ничего не может это изменение остановить так вот правильная гипотезы должен быть критерий эффективности Что такое

критерий эффективности это измеримый показатель того на основе чего бизнес будет принимать решение развивать или удалять функционал который запросили разработали и только что выпустили этот критерий должен быть достижимым измеримым и конкретным то есть прямо вот специфичным критерий должны быть ориентированы на более клиентов если интересно узнать подроб Что такое более клиентов Посмотрите одно из предыдущих видео на моем канале который называется чтобы я хотел знать 10 лет назад когда запускал свой стартап ссылка будет в описании к этому видео Ну и критерий эффективности должны быть логически связаны с критериями приемки User Story Что такое юзер Story будет чуть дальше пример вы хотите изменить дизайн лендинга вашего продукта И ожидаете что Ну это поднимет продажи тогда гипотеза формулируется следующим образом если мы внесем вот такие изменения в linding page в посадочную страницу то конверсия лендинга увеличится как минимум вот на такую величину вот увеличение конверсии и размер увеличения этого конверсии и будет критерием эффективности гипотеза должна иметь оценку ожидаемой прибыли это первый раз звучит сложно и рассчитать Это довольно сложно но все что отдается программисту все что отдается разработчику бизнес заказчик или продакт-менеджер или человек который отвечает за связь бизнеса и инженеров разработчиков программистов он должен уметь как-то очень высокоуровнево на пальцах но сделать прогноз ожидаемой прибыли от того что будет разработано например Наверняка вы знаете есть такая в электронной коммерции механика которая

называется брошенная корзина человек добавляет товар в корзину уходит с сайта без завершения покупки и ему через некоторое время приходит Push письмо может быть даже SMS с каким-то промо предложением и посылом продолжить оформление заказа но на более выгодных условиях так вот однажды к нам пришел клиент который сказал что у него довольно часто запускаются промо-акции и он предполагает что В корзине товары появляются скидка И это повод еще раз вступить в коммуникацию с клиентом который оставил корзину не завершив заказ что это должно подтолкнуть его к покупке мы проанализировали что в корзинах которые бросили в течение 7 дней 10 процентов товаров в среднем снижают свою Стоимость на пять процентов и больше Таким образом мы сделали отсюда Вывод что мы сможем с хорошей эффективностью отправлять на 10 процентов больше коммуникации о брошенных корзинах и соответственно получать на 10 процентов больше транзакций с этой механикой мы знаем сколько нам приносит одна такая транзакция умножаем это экстраполируем на 10 процентов и получаем конкретное число в рублях в деньгах сколько дополнительных денег мы можем заработать Вот такая вот последовательность Конечно же это не то это очень высокоуровневый приблизительная оценка но она Обязательно должна быть кто-то должен подумать Сколько денег в рублях мы заработаем с вот этой вот штуки которую хотим разработать дальше гипотезу бизнес заказчик сформировал мы помещаем ее в то что называется backlock Back Lock это место в Task Manager и где копятся задачи которые готовы к тому чтобы их брали в работу первый освободившиеся разработчики так вот чтобы задача попала в блок необходимо подготовить требования User Story и прототипы интерфейсов сейчас поговорим о том как это сделать так чтобы задача которую вам отдаст программист была сделана быстро чтобы ему не нужно было лишний раз изобретать велосипед и чтобы ему не нужно было потом брать задачу на доработку после того как Вы посмотрели и сказали что Это не совсем то что вы хотели во-первых

разбираемся с тем что такое User Story на эту тему написано много статей уверен что если вы это погуглите вы найдете очень много материалов я расскажу вкратце чтобы вы понимали что это за концепция и могли дальше погружаться в ее изучение это короткая формулировка намерения которая описывает что-то что ваш продукт система сайт мобильное приложение должны сделать для вашего пользователя понятное и заказчику и программисту и представляющую собой небольшой инкремент ценный функциональности которая может быть разработана вот прямо сейчас то есть мы не говорим что мы луну с неба хотим достать Мы хотим сделать Ну вот небольшой Шаг в сторону расширения ценности нашей платформы и нашей системы и это опциональность должна как бы иметь возможность быть реализованной в рамках нескольких дней работой программиста если User Story не укладывается в несколько дней ее нужно разбить на несколько User Story Кроме того юзер торри содержит критерии принятия и юскейсы сейчас разберемся с этими двумя понятиями 1 критерий принятия это приоритетный список критериев которым должен удовлетворять User Story чтобы разработанный функционал одобрил заказчик продуктовонор клиент Ну или кто-то еще какой-то еще с теххордер который отвечает за приемку функциональности А юскейс это последовательность действий пользователя в виде списка который содержит подробное описание того как человек с помощью функциональности который будет разработан достигает критерий принятия каждая возможность разрабатываемого функционала должна иметь свой собираем на этом месте Вот как это выглядит Вы описываете каждый User Story намерение короткое получить какую-то ценность у этого из истории есть название шаблон для заполнения из истории видно сейчас на экране Я как дальше название роли хочу что-то получить для того чтобы решить свою цель свою задачу или устранить свою боль вот все что здесь есть в фигурных скобках нужно заменить естественно на что-то из жизни дальше идет критерий принятия их может быть несколько и дальше перечислены юскейсы где пошагово пользователь проходит через те или иные этапы Ну что можно взять например допустим онлайн регистрация на авиарейс Я как пассажир хочу пройти регистрацию на рейс онлайн чтобы не стоять в очереди на регистрацию и сэкономить время вот такой User Story критерий принятия я распечатал посадочный талон у меня в руках посадочный талон время я на это потратил там не больше там 15 минут и Ну что-нибудь еще что можно ставить в критерии юскейс номер один мне на почту приходит письмо с предложением пройти онлайн регистрацию шаг номер один шаг номер два я нажимаю на кнопку в письме шаг номер три попадая на сайт шаг номер 45 и так далее до тех пор пока у меня в руках нет посадочного талона Юз кейс номер два мне приходит push-уведомления из мобильного приложения мои авиакомпании с предложением пройти онлайн регистрацию Я открываю приложение и так далее по шагам вот такой Юзер истории оформляется в полноценный документ который вы идете обсуждать программистом как это обсуждение проходит Сейчас расскажу до того как будет написано Хоть одна строчка кода отдельный человек который как правило называется дизайнер интерфейсов формирует прототипы интерфейса в том числе функциональные сейчас для этого есть очень много инструментов figma envision Ну и там другие популярные инструменты Так что когда вы приходите к программисту у вас уже есть готовые функциональный прототипы которые даже про кликать можно для того чтобы пробежаться по User Story и по всем кейсом которые вы хотите реализовать Обратите внимание что к этому моменту не было написано ни одной строчки кода человека часы программистов Это самый редкий ресурс это бутылочное горлышко любой it-компании Потому что всегда слишком много идей слишком много людей с этими идеями которые хотят их воплотить в жизнь и для того чтобы этот ресурс использовать максимально эффективно необходимо проделать Как вы видите очень большое количество исследовательской работы для того чтобы утилизировался этот редкий ресурс Ну с максимальной эффективностью Итак подготовили требования User Story прототипы интерфейсов дальше мы идем к разработчикам команде программистов для того чтобы получить от них оценку по сложности разработки для

этого классно подходит такой процесс который называется planning Pocker как он работает приходит бизнес заказчик вместе с может быть менеджером продукта к команде программистов и Объясняет что он хочет от них получить дальше когда бизнес заказчик рассказал Все что он хочет получить разработчики начинают задавать вопросы а как ты видишь вот это а как ты думаешь нужно сделать вот так Напомните пример с которого я начал это видео в нем были те самые вопросы которые программисты вынуждены додумывать когда остаются предоставленными сами себе эти вопросы задаются до тех пор пока каждый из команды разработчиков не скажет что у него больше вопросов не осталось а затем они в закрытую кладут вот такие вот карточки которые вы видите на скриншоте с цифрами дальше все переворачивают эти карточки и на этих карточках находится количество дней от 0 до 9 который по мнению каждого программиста необходимо потратить для того чтобы реализовать задачу которая только что обсуждалось который только что была на обсуждении и дальше модератор либо Project Manager либо может быть технический директор задает вопросы людям которые дали самую маленькую оценку людям которые дали самую большую оценку по срокам разработки У первых спрашивают как они видят что можно сделать так быстро у самой большой оценки спрашивают какие они видят сложности Почему они думают что это займет так долго дискуссия продолжается до тех пор пока все разработчики не сойдутся на одной и той же оценке кстати говоря эту встречу очень полезно записывать на аудио от начала и до конца и затем аудиофайл записью встречи прикладывать в Task Manager к этой задачке для того чтобы тот разработчик который возьмется за ее реализацию имел возможность вернуться к аудиозаписи что-то вспомнить что-то освежить в памяти получить какие-то ответы на вопросы это очень-очень-очень важно и полезно а само количество очков принимается за то что называется Story Point и об этом дальше поговорим Это довольно важный инструмент для повышения эффективности команды разработки Итак задача у нас в блоги у нее есть бизнес требования описанные из истории есть прототипы интерфейсов Была проведена встреча где с разработчиками обсудили как кто хочет видеть результат их работы и была получена оценка в днях Вот только

тогда эта задача попадает в backlock мы еще раз скажу к этому моменту не написали ни одной строчки кода А времени разработчика было потрачено Ну там 20-40 может быть 60 минут на эту задачу код мы еще не писали после этого только задачи с максимально выгодным для бизнеса соотношением прибыльности к стоимости разработки идут к программистам и делается первая версия называется mvp это аббревиатура от фразы минимум wible product то есть минимально жизнеспособная версия Мы никогда не хотим делать первую версию фичи какой-то очень крутой есть знаменитый такой человек который основал в кремниевой долине культовой акселератор который называется 500 стартапов так вот он Однажды на для выступлении сказал Старт защиты есть твой possible то есть запускайтесь на максимально плохой версии но она должна быть минимальна жизнеспособной она должна иметь возможность удовлетворить ее с кейсом она должна иметь возможность пройти критерии принятия которые вы указали в User Story Пускай это будет некрасиво Пускай это будет в ручном режиме ваша задача подтвердить что ценность генерируется отловить Баги и измерить результат по критерии эффективности выросла у вас конверсия или не выросла проходит вас люди быстрее регистрацию на полет или не проходит и на базе этого измерения результата уже принять решение о выпуске полноценной версии вы себе не представляете Сколько раз я просил разработчиков сделать функциональность которая была ну по моему мнению гениальный приведу такой пример когда в Retail Rocket у нас были механики на коммуникаций Ну а тех же брошенных корзинах Мы работали с очень большим количеством ритейлеров которые между собой не конкурировали и один из ритейлеров один из магазинов обратился к нам за таким запросом А давайте запустим кросс-промо с другим ритейлером с которым я не конкурирую например есть магазин электроники и инструментов и кто-то купил там шуруповерт есть магазин мебели Давайте предложим скидку с тем кто купил какую-то мебель на шуруповерт Почему нет мы реализовали такую механику конечно же вот внутри нашего процесса в минимальной версии мы не стали делать большой серьезный продукт который готов к масштабированию на весь мир на все сотни миллионов пользователей мы сделали в таком полу ручном режиме чтобы отловить пользователей которые купили что-то в одном месте или подумали о покупке чего-то и просто иметь возможность в ручном режиме запустить на них коммуникацию с предложением скидки идея была в том что человек приходит на магазин а при этом он не является подписчиком магазина а но он является подписчиком магазина б и от магазина б ему уходит промо-предложения вроде как все счастливы мы это сделали довольно быстро нашли на первом этапе клиентов которые согласились это протестировать выпустили mvp Как вы думаете Сколько таких компаний мы запустили за полгода ни одного ровно 0 ни один из ритейлеров так и не смог договориться ни с кем другим то у кого-то база больше то у кого-то средний чек выше топ правом предложений готовы предложить выгоднее один ритейлер чем другой никто не был готов работать по этой механике хотя сама по себе она была прекрасная очень высокая конверсионно и мы здесь приняли решение эту функциональность удалить Несмотря на то что она вот такая вот красивая потому что любая информационная система вы не можете представить ее себе как Карточный домик каждая новая фича которую вы выпускаете для ваших клиентов это слой карт в вашем карточном домике Если вдруг вы решите заменить какую-то карту на одном из нижних слоев качественный домик у вас развалится поэтому делать это не так просто и если какая-то функциональность вам не нужна тогда смело удаляйте ее для того чтобы не плодить то что называется технический долг легаси то что ограничивает как следующий уровень пирамиды ограничивает ваши возможности по изменению предыдущих уровней пирамиды и замедляет вашу динамику развития вашего продукта как только приняли решение о том что критерии эффективности у нас достигнуты и фича действительно будет приносить нам те деньги которые мы хотим мы уже делаем полноценную версию этой фичи выпускаем ее Тестируем и в обязательном порядке проводим следующие шаги обязательно презентовать это команде сделайте

какой-то демо день раз в месяц раз квартал раз Ну хотя бы в год когда человек который управляет продуктом рассказывает что нового появилось в нашей системе к вам все время приходит в команду Новые люди которые не так хорошо понимают ваши платформе у вас появляются клиенты они задают какие-то вопросы нужен Поток информации о том что новенького происходит в вашем продукте в вашем приложении на вашем сайте допускаются маркетинговые активности вы постите в соцсетях записываете видео пишите документацию делайте e-mail рассылки пользователям вашего инструмента вашего приложения вашего сайта о том что у вас появилось но наращивание функциональности это наращивание ценности для ваших клиентов Ну и конечно же собирайте обратную связь и начинаете формировать такие же требования к следующей версии того что вы сейчас выпустили что еще хочу сказать отдельно что помогает повысить эффективность во-первых это визуализация Вы можете сделать я вам предложу два таких инструмента Первое это Канбан доска из вашего тест-менеджер и стрелы с джиры из там того что вы используете полностью продублированная где-нибудь на стене в вашем офисе где в столбиках есть этапы развития продукта у нас в какой-то момент процесс разработки продукта вот дошел до такого огромного количества этапов которые вы видите на фотографии зачем это нужно во-первых каждый человек знает чем занимается команда программистов Какая задача сейчас в чьей зоне ответственности и на какой стадии То есть можно примерно прикинуть когда она будет готова каждый бизнес заказчик знает что происходит с его задачкой где она сейчас кроме того программисты тоже знают что вся остальная команда видит все время держит в фокусе их работу Это довольно важно Это первый Тип визуализации который вы можете использовать в офисе второй Тип визуализации который может использовать в офисе это те самые истории поинты на этапе планинг покер у каждой задачки появилось количество дней оценочно которые разработчики считают что потребуется для этой задачи так вот каждой задаче каждой задачи присваивается количество очков вот исходя из этой оценки а затем мы фиксируем когда задачи выходят в релиз Сколько очков мы залили в этом месяце как команда управления продуктом как команда разработки и где-то в офисе вешается график по неделям по месяцам по каким-то продуктовым направлениям Сколько стори-поинтов за этот период времени дошло по команде в целом и может быть даже по каждому конкретному сотруднику таким образом продуктивность команды разработчиков всегда будет прозрачно и у всех на глазах Кроме того можно будет сравнивать по эффективности и находить тех кто эффективнее те кто менее эффективен но это уже работа для технического директора не совсем для менеджмента дальше очень важный тезис задачки без оценки профита в деньгах на

самом деле внутри процесса наращивания функциональности не нужны это может быть контур интуитивно Я помню один раз в Питере я рассказывал вот этот тезис довел его до аудитории и встала девушка которая говорит мою задачу тогда никогда не возьмут в работу ее невозможно и деньгах Я говорю какая вас задача нагреть Я занимаюсь логистикой кладовщики я уже два месяца требуют разработчиков 1С чтобы они сделали кнопку моим кладовщикам который будет печатать накладную сразу с двух сторон потому что они вынуждены печатать что-то там идти куда-то далеко к принтеру переворачивать бумажку на в другую сторону опять идти к компьютеру нажимать печать они в половине раз ошибаются портят бумагу и в общем если посмотреть сколько накладных они печатают если они тратят по 2 минутки лишнего времени на каждую накладную то у них уходит два часа в день только вот на это невозможно посчитать деньгах Ну как же это невозможно посчитать деньгах два часа в день умножаем на количество дней умножаем на стоимость человека часа кладовщика И говорим что вот столько денег нам стоит эта работа при этом говорим о том что если мы столько человека часов кладовщика высвободим то он заработает нам вот столько денег Ну сами Оцените что там за лишние два часа кладовщик может сделать если он что-то не успевает и эта задача станет блок и будет сортироваться и она говорит Ну так кладовщик больше денег не заработает И тогда какие-то дополнительного от этой задачи не будет ее никогда не возьмут в работу и я ей это возвращаю вы понимаете что вы только что сказали программисты не возьмут в работу задачу которые не принесет дополнительных денег бизнесу не сэкономит не заработает дополнительно ничего она действительно тогда не нужна в работе она с этим не согласилась но для многих людей в аудитории на тот момент это было довольно серьезным открытием Ну и последний момент который

хочу сказать что у многих разработчиков не буду говорить что у всех есть некоторая система распознавания свой чужой знаете как военной авиации у истребителей и ракет что ракета не сбила свой самолет есть такая система опознавания свой чужой так вот в программистов в некоторых скажем так но это не редкость встроена такая же система вы приходите к ним с каким-то запросом они забрасывают вас непонятными вам терминами и аргументами который вы не можете парировать потому что вы ну не понимаете о чем вообще идет речь они это видят что дискуссию с вами Может таким образом вести и начинают вами манипулировать просто говорят что сделать то что вы хотите нельзя в таком виде ли вообще нельзя или это будет не так быстро как вы ожидаете потому что вот набор причин со словами в которых вообще ничего не понимаете если они видят что вы поддаетесь то это становится системой потому что они поняли что вы Чужой и вас можно таким образом атаковать потому что ну почему нет Как стать своим очень просто Пройдите базовый курс программирования у меня в предыдущем бизнесе к менеджерам по работе с клиентами это было требование на испытательный срок если не знаете где это сделать Я вам дам подсказку кода cademy. com базовый курс по javascriptu за 1-2 месяца в спокойном режиме с блокнотиком за пару вечеров в неделю вы от абсолютного непонимания Что такое программирование простые концепции переменных массивов операторов циклов дойдете до создания собственной небольшой игры с помощью объектно-ориентированного программирования и сможете с разработчиками говорить на одном языке больше не будет такой ситуации в которой вас распознают чужого вы станете своим я вам это гарантирую это очень-очень важно инвестируйте в свое собственное развитие Если вы хотите работать внутри it Ну и Кроме того Рекомендую вам прочитать вот

такие вот две хорошие книги книга по моему я рекомендовала в прошлом видео она есть на русском языке и вот такая вот книжка Интерком он продакт менеджмент очень классная книга по управлению продуктом от Интерком она распространяется бесплатно Я ее положу прямо файлом в своем Telegram канале ссылка на мой телеграм-канал будет в описании к этому видео Ну а у меня на эту тему Все если остались вопросы по тому как выгодно эффективно выстраивать процесс работы Сойти с программистами с разработчиками или вы хотите как-то эту тему расширить Напишите в комментарии к этому видео что еще хотите узнать о чем еще можно поговорить Спасибо И увидимся в следующем видео