Я руковожу направлением 1С в компании S7, которая входит в холдинг S7 Airlines. Я расскажу вам, как устроена команда 1С, которая ориентирована на продукт, остановлюсь на роли владельца продукта в этой команде, и в заключение расскажу историю, как продуктовый подход спас одну из наших самых важных 1С-систем.
О компании
В команде 1С компании S7 больше 20 сотрудников, каждый из которых входит в одну из продуктовых команд – их у нас 4: «Бухгалтерия предприятия», «Зарплата и управление персоналом», ERP и «Документооборот». Это – штатные сотрудники, из них 5 программистов, остальные – консультанты.
Есть пул внешних программистов, консультантов, подрядчиков, которых при необходимости мы привлекаем к одной из таких продуктовых команд – они непостоянные.
Как устроена команда продукта
Как я говорил, каждый сотрудник у нас относится к команде какого-то продукта. Нет ни одного человека, который был бы сам по себе, нет выделенных менеджеров, выделенных аналитиков – все принадлежат какому-то продукту.
- Состав команды продукта постоянный: Самая маленькая команда – два человека, это бухгалтерия. А самая большая команда состоит из 8 человек – это ЗУП и ERP.
- Команда продукта автономна, она может самостоятельно поддерживать свой продукт в хорошем состоянии, чтобы он выполнял свои функции, и дорабатывать его без привлечения сторонних ресурсов. Со стороны им для этого никто не нужен – они сами со всеми своими делами справляются, им никого не нужно ждать.
- В команде всегда есть владелец продукта, всегда есть программисты (1-2 человека) и несколько консультантов.
- Но в команде нет выделенных аналитиков, руководителей проектов, тестировщиков и технических писателей. Такие роли у нас есть, но выделенных на это людей нет, хотя каждый из членов команды все это умеет: делать аналитику, ставить задачи, принимать их от заказчика и ставить программисту, руководить небольшими или большими проектами, тестировать.
Почему команда продукта устроена именно так? Дело в том, что команда производит две вещи:
- поддерживает пользователей с соблюдением SLA – соглашения об уровне услуг;
- улучшает рабочую версию продукта.
На тезисе про улучшение продукта я хочу остановиться подробнее, потому что как раз здесь начинается продуктовый подход. Что значит «улучшает»?
- Это не всегда и не обязательно добавление каких-то новых фич. Иногда новые фичи ухудшают продукт, и нужно мужество и смелость это признать – в этом случае фичи надо убирать.
- Важно найти то, что продукт улучшает, – это главная задача владельца продукта. Мы ориентированы не на создание артефактов вроде ТЗ, плана тестирования, инструкции или какого-то описания – это все промежуточные результаты. Мы нацелены на то, чтобы улучшить именно рабочую версию продукта.
Почему важно не останавливаться на промежуточных результатах? Очень часто при работе в каком-то асинхроне, когда роли выделены, бывает так:
- аналитик написал ТЗ, передал программисту, тот написал код – пока все было сделано, прошло несколько месяцев;
- и когда мы начинаем это в очередной раз показывать заказчику, у него уже изменилось представление о том, как все должно быть – заказчик, например, сходил в отпуск, отдохнул, у него появились свежие идеи;
- в итоге вся или половина работы, которую мы провели и на которую потратили время, пользы не принесла, ее можно списывать – то есть неготовая, недоделанная, недошедшая до рабочей версии продукта фича протухает.
Кто такой владелец продукта
Главная задача владельца продукта – стремиться к максимизации ценности продукта. Что мы под этим понимаем?
В ИТ-продуктах, которые есть на рынке, типа стартапов, все понятно – там у продукта есть какая-то рыночная цена, она растет или падает в зависимости от принятых решений.
А в корпоративном мире такого нет. Вы не сможете капитализировать свой продукт никак, но все равно у продукта есть ценность, и ее изменение все хорошо понимают. В чем она заключается? Когда ваш продукт становится более ценным, обретает более широкую базу довольных пользователей, которые рассчитывают ваш продукт развивать и пользоваться им дальше, не меняя ни на что, вы сможете ощутить это в обратной реакции от бизнеса:
- вашу команду могут расширить – вы сможете своих сотрудников поощрить, повысить, получить побольше бюджет и потратить его на всякие интересные вещи типа аналитиков и консультантов по узким вопросам со стороны и так далее;
- меняется отношение к вашим нуждам у сторонних команд, которые также занимаются поддержкой (например, сети или компьютеров) – если ваш продукт хороший, к нему будут относиться совсем по-другому, чем, если он будет неуспешный, никому не нужный.
В общем, все сразу ощущают положительное изменения ценности вверх и понимают, что есть смысл к этому стремиться.
Что значит владеть продуктом?
- Во-первых, владелец продукта владеет собственными знаниями и опытом. Наши владельцы продуктов одновременно являются крутыми консультантами, хорошо знают учет и конфигурации 1С, на которых построен продукт. Возможно, кто-то из них был руководителем проектов, как я, кто-то руководил большими и не очень большими отделами. В любом случае каждый из них является консультантом.
- Кроме этого, владелец продукта владеет командой, принимает ключевые кадровые решения. Изначально, кстати, команда состоит из одного владельца. Сначала подбирается владелец продукта, а потом уже можно собрать команду, помочь ему в этом.
- Он владеет бюджетом, принимает решения, на что потратить деньги – на внешних консультантов или на новый сервер, или еще на что-нибудь.
- Также он владеет бэклогом.
Скажу пару слов про бэклог. Это список задач с приоритетами.
- Наверху – задачи, которые максимально повышают ценность продукта, их имеет смысл делать в первую очередь.
- Посередине задачи, которые ценность имеют, но они на вторых ролях, мы их когда-нибудь потом сделаем.
- Где-то внизу остаются задачи с около нулевой ценностью, их можно делать, а можно не делать. Обычно они в этом состоянии находятся месяцами – чисто из политических причин. Проще ответить: «Давайте поместим задачу в бэклог, а потом сделаем, как руки дойдут», чем отказать вообще. Но всегда появляется что-то более приоритетное, и руки так и не доходят до таких задач.
- Самое интересное, что есть задачи, которые продукт ухудшают. Они «под полом», закрыты люком, и владелец продукта их там всеми силами удерживает, чтобы они не вырвались и продукт не ухудшили. Чуть позже расскажу, как это можно делать.
Владея всем этим, владелец продукта принимает взвешенные решения по продукту – куда его развивать, какие фичи нужны, какие не нужны. И делать это нужно максимально быстро.
Почему важно принимать решения быстро? Компания у нас большая, айтишников – несколько сотен, заказчиков тоже сотни. Можете себе представить, как это сложно устроено иерархически – куча начальников, куча отделов, куча интересов. В этом смысле команда 1С выгодно отличается от многих других айтишных команд. Как это выглядит? Если на встречу по каким-то вопросам приходят представители двух команд: со стороны 1С – владелец продукта, со стороны другой команды – формальный менеджер, который управляет по классической, не продуктовой технологии, то:
- владелец продукта 1С сразу на встрече принимает какие-то решения или отклоняет их, приводя какую-то аргументацию – может быть, он возьмет с собой какого-то предметного консультанта, который глубже знает тему;
- а человек из другой команды выслушает, запишет, пойдет совещаться с начальником отдела разработки, отдела аналитики, еще с какими-то начальниками, и только потом придет с какими-то решениями.
Поэтому отношение к нам несколько лучше.
И владелец продукта отстаивает решение, принятое им, в интересах продукта, а не заказчика.
Основное назначение продукта
Как удерживать вредные фичи, которые пытаются вырваться и испортить продукт? В этом может помочь такое понятие как основное назначение продукта.
Я приведу такое назначение для двух продуктов – «Бухгалтерии» и «Документооборота».
- Для «Бухгалтерии» основное назначение – «бухгалтерский учет дешево». Как можно на примере это использовать? Иногда приходят странные требования, например, добавить одно-два-три субконто или поменять механизм проведения стандартных документов до неузнаваемости, чтобы получить какой-то профит. Заказчик считает, что это стоит того. Мы говорим: «Здорово, но это противоречит назначению продукта, получится дорого. Или мы утратим бухгалтерский учет, мы не сможем пользоваться обновлениями вендора, а бухгалтерский учет, который не соответствует свежим требованиям, уже нельзя назвать бухгалтерским учётом. Или это будет система с большой командой поддержки, чтобы как-то будет приспосабливать обновления вендора под сильно переделанную 1С. Но на это нужно много денег». Обычно на этом моменте заказчик успокаивается и перестает требовать это, по крайней мере, от «Бухгалтерии». Думает уже про ERP или другие крутые системы, а «Бухгалтерию» терзать перестает.
- Для «Документооборота» назначение – быстрое согласование документов широким кругом пользователей. «Документооборот» тоже немножко страдает от требований добавить дополнительных согласующих, чтобы они заполняли всякую интересную аналитику в интересах бухгалтеров, финансистов и юристов. Мы такие требования слышим очень часто. Но мы на это не соглашаемся, потому что все эти лишние согласующие и лишние дополнительные поля приведут к тому, что согласование документов станет медленней – обычный секретарь уже не сможет просто заполнить эти поля, ему придется все уточнять у бухгалтеров и экономистов, все согласование будет медленнее.
Так апелляция к основному значению продукта помогает открещиваться от вредных фич.
Как выстроены коммуникации
Немного о коммуникациях в команде. Мы стараемся убрать барьеры и сделать общение максимально прозрачным:
- мы убираем барьеры внутри команды – ядро команды, которое у нас в штате, сидит вместе, у нас open space, все общаются голосом, иногда по почте;
- для постановки задач мы используем Jira;
- также мы стараемся убрать барьеры в общении с заказчиками и подрядчиками, например, с заказчиками и подрядчиками мы общаемся тоже с помощью Jira, чтобы была максимальная прозрачность.
Как это выглядит?
- Консультант или я, услышав на рабочей встрече, что есть такая задача, создаем тикет в Jira.
- Консультант проговаривает основные требования с заказчиком, фиксирует их в тикете, и там же в Jira они вместе с заказчиком обсуждают какие-то детали: всплывают новые подробности, у консультанта возникают вопросы, заказчик на них отвечает, добавляет что-то новое. Все это продолжается до тех пор, пока консультант и заказчик не договорятся. Получается такое размазанное ТЗ прямо в комментариях.
- Там же в тикете подводится некая черта – ставится задача программисту, где уже начинают общаться консультант и программист.
- И последняя часть жизненного цикла – когда начинается тестирование и передача заказчику.
Мы немножко боялись, что пустив заказчика в Jira, мы получим негатив. Заказчик может посмотреть, как работает ИТ, ужаснуться, относиться к нам плохо или угорать над нами и нашими ошибками. Но на самом деле это дало положительный результат для сложных задач, где много подводных камней и неочевидных вещей, которые заказчик сразу не продумал. И когда он видит, что команда на эти подводные камни натыкается, как-то их решает, обходит, у них возникают новые и новые вопросы, заказчик уже не ругается на нас из-за задержек – он видит, что причины задержки объективные. И такой эмоциональный фон на сложных доработках, у которых сорваны сроки, гораздо проще.
Важно еще, что команда общается с бизнес-пользователями напрямую. У нас нет посредников в виде бизнес-аналитиков или проектных менеджеров. Мы готовы общаться с бизнес-пользователями любого уровня, лишь бы они хотели. Некоторые хотят. Некоторым, кстати, на фоне общения с бизнес-аналитиками и проектными менеджерами интересно пообщаться с командой из предметных программистов и предметных консультантов. И я считаю, что это тоже наше преимущество.
Развитие и обратная связь
Пару слов об обратной связи. Мы очень любим обратную связь.
- Самая лучшая обратная связь для нас – это опыт на рабочей базе. Но если там будут ошибки – то, скорее всего, есть риск, что это уже поздно. Поэтому мы стараемся, прежде чем выложить доработку на рабочую базу, получить обратную связь каким-то другим способом.
- Отлично – если пользователи ее протестируют на тестовой базе. Некоторые пользователи так делают, мы им даём доступ к тестовой базе, они придумывают свои кейсы, тестируют и пишут нам, что не так. Спасибо им, но так делают не все. Некоторые категорически отказываются.
- Хорошо – это то, на что мы ориентируемся в своей работе. Мы проводим демонстрацию, готовим для демонстрации MVP (минимальный жизнеспособный продукт). Это недоделанная фича, но она дает представление, как все будет работать. Мы проводим демонстрацию, сами придумываем какие-то кейсы, максимально близкие, как нам кажется, к работе и к реалиям заказчика. Заказчик, видя знакомые фамилии, знакомые справочники и так далее, вовлекается, накидывает еще кейсов, и мы очень дешево получаем много-много качественной обратной связи. Мы не сильно дергаем этим заказчика – сама демонстрация проходит недолго, но при этом мы не рискуем испортить продукт из-за того, что фича будет не готова.
- Так себе – это мокапы и иллюстрации. Мокапы – это наброски интерфейсов, иногда интерактивные. Там можно нажать на кнопочки, но данные не ввести, и заказчик на них может только посмотреть. Поэтому мы считаем, что мокапы дают обратную связь «так себе». То есть если мокап или иллюстрация согласованы, это в принципе мало что значит. Вы потратите время, сделаете прототип продукта, а заказчик посмотрит и скажет, что все надо переделывать, и ссылка на то, что мокап согласован, не сильно поможет.
- Совсем бесполезным для себя мы считаем бумажное ТЗ – то, которое написано в ворде или в другом подобном формате. Заказчик и так перегружен всякого рода документацией, регламентами, информационными письмами. Он читает по диагонали, видит знакомые термины и часто делает такой вывод: ребята написали ТЗ, вроде, буквы русские, картинки есть, время потратили, наверное, ТЗ хорошее, и согласовывает его. Но это ничего не значит. Если сделать программу, фичу по согласованному бумажному ТЗ, очень часто потом ее не сдашь. Поэтому мы им не пользуемся, ТЗ пишем размазанное в Jira. Еще одно назначение бумажных ТЗ – это устраивать разборки, кто виноват и что делать, кто нарушил сроки и почему. Но для этого хватает и Jira. И кстати, когда мы ТЗ делаем размазанным в Jira в виде диалога с заказчиком, обычно до разборок не доходит. Зачем разбираться, если и так понятно, что были подводные камни – проблемы, которые сразу невозможно было учесть.
Инструменты
Расскажу про инструмент, которым мы пользуемся для поддержки наших пользователей.
Поддерживаем мы пользователей сами. Мы не передаем функции поддержки отдельной команде – поддержкой занимается продуктовая команда самостоятельно, причем поддержкой занимается и каждый член команды, и команда в целом. Получается такой спектр:
- На одной части спектра люди в команде, которые занимаются в основном поддержкой и небольшими несложными задачами развития. Спасибо им, потому что этих несложных задач обычно тьма, они касаются или печатной формы, или каких-то настроек отчетов, или каких-то мелких доработок, которыми можно завалить любого специалиста. А они это берут на себя.
- На другой части спектра – сложные задачи. Есть консультанты, которые занимаются сложными задачами и сложными вопросами поддержки.
- Остальные специалисты находятся где-то в середине спектра.
Сама поддержка у нас в нашей собственной системе учета заявок (СУЗ). Мы пробовали разные другие системы, распространенные на рынке (Redmine, Jira, Omnitracker), но ничего не зашло, поэтому наши ИТ-шники написали свою.
Этим инструментом пользуются и все остальные айтишные команды, и даже некоторые другие отделы – например, call-центр и другие неайтишные команды, которым он приглянулся. Потому что он универсальный и удобный.
Что мы смотрим в системе учета заявок? Мы смотрим соблюдение двух параметров.
- Первый параметр – насколько быстро мы берем заявки в работу – время реакции.
- Второй параметр – как долго мы их решаем – время выполнения.
В системе учета заявок настроены основные параметры, исходя из соглашения об уровне услуг (SLA):
- время поддержки – 8*5, 12*5;
- и нормы этого времени ответа на каждый тип заявок;
- есть еще более глубокая градация – например, ошибки и инциденты делятся по типам и по разному типу устанавливается разная норма времени, но обычно до этого не доходит.
Интересно, что мы в систему учета заявок впускаем сторонних подрядчиков. Что это значит? Раньше я говорил о четырех больших продуктах, которые у нас есть – Бухгалтерия, ЗУП, ERP и Документооборот. Там работают постоянные команды, есть постоянный фронт работ, люди профессионально сфокусированы на этих продуктах.
Но есть и другие 1С-системы, более мелкие. Их могут принести в любой момент и сказать: «Вот тебе 1С – она твоя, пожалуйста, поддерживай». Создавать продуктовую команду под них бессмысленно, даже не беря вопрос денег – там слишком мало работы. У какой-нибудь маленькой УТ на 5 пользователей очень мало процессов и очень мало документов – проблемы возникают редко, и развития почти нет.
Поэтому мы ищем подрядчиков со стороны. Тех, кто нам понравится, кто готов на наших условиях работать, мы подключаем к нашей системе учета заявок. Для пользователя это совершенно прозрачно, он не видит, какой команде заявка будет направлена. А мы в системе учета заявок можем смотреть, как подрядчик поддерживает нашу 1С – следить, чтобы он грамотно и корректно отвечал на заявки, отрабатывая инциденты.
На этом слайде представлена пара отчетов из наших систем учета заявок.
- Слева показан показатель времени принятия обращений в работу. Это месяц март, продукт – Документооборот. Почти 1000 заявок, ни одну не просрочили – время на взятие в работу в среднем полчаса. Стопроцентное качество у ребят.
- Средняя картинка показывает, как мы выполняем заявки. Здесь 6 штук были выполнены с превышением нормы, то есть качество получается 99,4%. Это очень высоко, выше, чем надо, потому что норма – 95%.
- А справа на картинке – разбор 6 инцидентов (тех самых красных точек, по которым было превышено время выполнения). Пять из них неинтересные, скучные – это команда по документообороту ответила не вовремя. А еще одна колонка поинтереснее, она разбита на три части. Эта заявка касалась того, что какой-то принтер что-то не печатает из Документооборота. И пока разбирались, кто виноват (команда, которая занимается принтерами, или команда, которая занимается сетью, или команда, которая занимается рабочими местами), прошло время. В результате здесь видно, что:
- команда Документооборота (синенькая часть) – молодцы;
- команда Service Desk, которая маршрутизирует заявки (это первая линия поддержки), – тоже молодцы;
- а команда, которая занимается принтерами, на которую эту заявку поставили – возились немножко дольше и подпортили статистику.
Такие полосатые столбцы руководство периодически смотрит и делает какие-то выводы о совершенствовании взаимодействия ИТ-подразделений.
Еще один параметр, который мы недавно стали мерить, – это скорость 1С. Вопрос с повышением производительности 1С – сложный. Мы своей целью ставим знать, что 1С начала тормозить до того, как пользователь будет жаловаться. Сделали вот такую тепловую карту, куда выводятся показатели Apdex.
Там, где выделено красным, скорость была меньше, чем надо – меньше нормы.
Как продуктовый подход помог спасти документооборот
Напоследок расскажу про то, как продуктовый подход помог спасти одну из наших ключевых систем. Речь идет о Документообороте. В отличие от других трех продуктов эта система была не в моей команде, у нее был свой отдельный менеджер и небольшая команда из четырех человек.
- Помните, я говорил про 100% качество поддержки? Это было время глубокого кризиса системы. Поддержка работала хорошо, но сама система работала плохо, тормозила, документы согласовывались очень долго, потому что система была перегружена дополнительными согласованиями, дополнительными полями и прочим. Интерфейс был неудобный. Но главное – ничего не менялось. Команда, созданная по классической технологии с выделенным менеджером, четким разделением ролей поддержки от развития, не могла справиться с такими проблемами. Смотрите, поддержка-то работает хорошо, 99,4% при норме 95% – это лучше, чем надо.
- но улучшала ли команда рабочую версию продукта? Нет!
- Вместо этого:
- менеджер ходил к заказчику и согласовывал с ним план развития на месяц – план хороший, подкреплен ресурсами, команда все может выполнить.
- менеджер приносит согласованный план в команду, команда его получает, аналитик готовит ТЗ и согласовывает его с заказчиком.
- программист что-то разрабатывает по ТЗ, отдает аналитику на тестирование (или сам программист тестирует).
Все хорошо – код качественный, все молодцы. Поддержка, как я уже говорил, хорошая, но продукт в целом – не очень.
Что мы сделали, чтобы ситуация изменилась? Когда этот продукт перешел ко мне, я разглядел в одном из программистов задатки владельца продукта.
- Во-первых, это готовность увеличивать ценность продукта, а не следовать желаниям заказчика, а их там, кстати, много – всех не удовлетворишь.
- Во-вторых, готовность заниматься не только вопросами функциональности – делать новые фичи, но и общаться с заказчиком, чтобы какие-то фичи урезать и сделать продукт удобным – поменять для этого какие-то нормативные документы, потому что так работать невозможно.
- И третье – упорство в достижении этих целей.
В общем, у Документооборота появился владелец. Это программист, у него не было опыта руководства командой, не было опыта разработки формального ТЗ, он никогда не общался с заказчиками высокого уровня. Но ничего страшного.
Тех качеств, о которых я говорил, и тех ресурсов, что мы даем владельцу (команду, бюджет, все возможности) было достаточно для того, чтобы вывести Документооборот за несколько месяцев из глубокого кризиса:
- Теперь он быстрый – документы согласовываются в разы быстрее и будут согласовываться еще быстрее.
- Мы написали новый интерфейс.
- В итоге за несколько месяцев команда того же состава (состав остался ровно тем же – 4 человека) улучшила продукт сильнее, чем та же команда при стандартном подходе за 1,5 года.
Так мы используем продуктовый подход – он помогает нам создавать новые продукты качественными и поддерживать их в таком состоянии.
У меня на этом все. Всем спасибо.
Вопросы
- Почему многие не готовы использовать продуктовый подход? Боятся? Или бизнес не готов?
- ИТ боится. Многие руководители боятся вожжи отпустить.
- Я услышал в докладе, что владельцем продуктовой команды стал ИТ-специалист, программист. Сейчас зачастую продуктовые команды возглавляют бизнес-люди, те, кто больше ориентирован на бизнес-показатели.
- Да, это тоже есть. И я вполне допускаю, что для новых продуктов я буду подыскивать человека именно из бизнеса. Но если у человека есть здравый смысл и понимание, что для продукта полезно, а что не полезно, у него, я думаю, будет успех.
- Вы говорили, что у вас команда из 20 человек на 4 продукта. У вас за месяц было 950 заявок – и это только по одному из продуктов. То есть у вас команда из 4 человек смогла 950 заявок обработать, и при этом у вас нет завала по заявкам? Мне просто очень интересно, как у вас так быстро решаются задачи. Чуть ли не в течение 50 минут.
- Документооборот у нас типовой, и нас никто не просит о чем-то сложном, как в Бухгалтерии или ЗУП, где можно день-два «голову греть». В Документообороте заявки проще, и они все типовые.
- Правильно я понимаю, что эта статистика была больше по заявкам к консультантам, а не к разработчикам?
- Да.
- Потому что я был удивлен: у вас 1-2 разработчика, а вы столько заявок обрабатываете.
- Нет, мы по 900 фич в месяц не делаем.
- Есть понятие «технический долг». Когда у вас все фичи так быстро внедряются без особых ТЗ, не нарастает ли из-за этого «технический долг»?
- Нарастает, конечно. Честно. Но что мы делаем с техническим долгом? По тем фичам, которые очень нужны и которые по каким-то причинам плохо работают, тормозят, например, мы привлекаем стороннего специалиста, который умеет оптимизировать код. Он делает чудеса. Если найдете такого хорошего специалиста, классно. Есть примеры, когда код оптимизировали в 150 раз. Причем программист, который его изначально писал, был опытным и хорошим. Таким образом, мы эти вопросы решаем точечно.
- Еще вопрос: ваша система заявок как-то связана с Jira?
- Да. Большая часть заявок закрывается прямо в системе учета заявок и не ставится на какое-то ожидание. Мы из вежливости ставим заявки в статус ожидания пользователя, потому что мы не имеем право сказать, что проблема решена, мы ждем подтверждения от пользователя. И этот канал системы учета заявок – это одновременно и канал поступления новых дополнительных требований, заявок на фичи. Мы фиксируем их в СУЗ и Jira, а потом связываем. Эта система написана не на 1С, это на нашем внутреннем сайте. Простая легкая красивая интерфейсная 1С.
- Вы сказали, что будущей команде рискнете поставить человека из бизнеса. А не боитесь, что человек без технического бэкграунда будет очень долго понимать сложность реализации задачи и продавливать команду? Пример из жизни: многим пользователям кажется, что задача «добавить кнопочку» занимает 3 секунды. И только человек с техническим бэкграундом понимает, что надо перелопатить половину инфраструктуры, чтобы все заработало. Не боитесь, что будет деградация производительности на внутренних коммуникациях, что команда будет сопротивляться ему?
- Ключевой момент – этот человек не должен быть со стороны, он будет в команде. Если человек будет со стороны, так и будет, и так и есть. У нас есть в других направлениях владелец со стороны. Между ним и командой конфликт, стена. Но если ее убрать, его поставить в команду, он будет доверять команде, они будут одно дело делать вместе.
- То есть владелец не сможет опереться на свое экспертное мнение, он найдет себе экспертов в команде, и тогда конфликта не будет?
- Да. Я больше скажу. Я сам, честно говоря, уже отошел от технического бэкграунда, и не могу понять, к чему что приведет. Но я верю команде, и если они говорят, что это дорого, я говорю заказчику, что это дорогая фича, лучше ее не делать. Я верю команде. Действительно, либо бизнес начинает находить экспертов внутри коллектива, который начинает слушать, либо есть второй вариант, когда уже бизнес становится более айтишным. Сейчас уже ни одно направление не обходится без ИТ-технологий, и бизнес-люди тоже поднимают свой уровень. Поэтому все ищут тех, кто уже обучается по новым программам, с двумя направлениями – какой-то специализированной и ИТ.
- Я не совсем понял две вещи. Во-первых, что у вас является продуктом? Вы перечислили, что у вас 4 отдела по конфигурациям. Получается, у вас владелец продукта – это Бухгалтерия, допустим. И это направление сразу отвечает за развитие кастомизированных конфигураций под каждого клиента.
- Дело в том, что мы не работаем на внешний рынок, у нас внутренняя ИТ-структура, inhouse-разработка. У нас одна конфигурация Бухгалтерии распространена на 20-30 юрлиц. Это и есть один продукт. Вполне возможно, что будет еще одна. У нас так с ERP: есть одна большая сложная ERP, а остальные – маленькие простые. И с ЗУП тоже – одна очень сложная у авиакомпании, а остальные – маленькие, простые. И это разные продукты, и у них разное основное назначение. ЗУП у простых компаний – это стандартная конфигурация с небольшими изменениями, а в ЗУП авиакомпании все переделано.
- У ЗУП каждой компании свой владелец?
- Да, для каждой конфигурации свой. Мы считаем, что это два продукта. Я не стал это сегодня расписывать, чтобы не усложнять, но это 2 продукта, у них разные бюджеты, разный подход. Команда одна, правда.
- То есть один человек может быть владельцем нескольких продуктов?
- Да.
- Понятно. И второй вопрос. На одном из слайдов, где был процесс планирования, говорилось, что менеджер планирует план доработок по данному продукту, аналитик готовит ТЗ и так далее. А где здесь владелец продукта? Когда и где он решает, что эта фича войдет в наш следующий релиз, допустим.
- Менеджер по классической схеме снимает с команды трудоемкость, чтобы понять, сколько может сделать, собирает с заказчика приоритеты. А владелец продукта к этому добавляет свое понимание ценности для продукта. Он, например, может сказать, давайте добавим субконто в Бухгалтерию. Это дешево, правда, и вы добавляете. Но потом будут безумные проблемы с обновлениями, в целом это будет очень дорого.
- Я об этом и спрашиваю. Менеджер – это тот, кто принял заявку-пожелание от клиента, и получается, что на слайде пропущен этап, что он это согласовывает с владельцем продукта.
- Нет. Вы неправильно поняли. Там было противопоставление команде, где есть менеджер и аналитик, но нет владельца продукта. Это была иллюстрация противоположного подхода.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
