Как устроена команда 1С, ориентированная на продукты, и какую роль в ней занимает владелец продукта

Публикация № 1257387

Методология - Управление командой

Для развития продукта важен продуктовый подход и владелец продукта, который знает, что надо сделать в первую очередь, а от чего пока стоит отказаться. Почему это базовое требование, и чем продуктовый подход в 1С выгодно отличается от традиционного, на конференции Infostart Event 2019 Inception рассказал руководитель направления 1С компании S7 IT Станислав Алексенко.

Я руковожу направлением 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 в Москве.

Выбрать мероприятие

Специальные предложения

Оставьте свое сообщение

См. также

Как настроить правильную техподдержку (helpdesk, service desk на коленке) Промо

Управление услугами и сервисом Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Монитор заказов Учет рабочего времени Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Монитор заказов Учет рабочего времени v8 УУ Бесплатно (free)

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

24.04.2019    15833    0    siddy    0    

Замеры APDEX против "ощущений" бухгалтеров

Автоматизация ИТ-компании Бесплатно (free)

Очень часто пользователи недовольны, как работает информационная система. Но даже когда ИТ-специалисты все полностью меняют, пользователи остаются недовольными. О том, как объективно оценить проведенные изменения, на конференции Infostart Event 2019 Inception рассказал руководитель ИТ-службы ИООО «Лукойл Белоруссия» Роман Жульпо.

24.04.2020    3513    0    it-boy    19    

Где взять программистов, если вы не Google или Яндекс, и ваш офис расположен не в Москве?

Автоматизация ИТ-компании Бесплатно (free)

Многие отечественные компании сталкиваются с нехваткой квалифицированных кадров, особенно если расположены в небольших городах. Вузы специалистов не готовят, отбирать у конкурентов – дорого, приглашать из столиц – еще дороже, да и никто не согласится. Как же быть? Об одном из решений проблемы подготовки специалистов рассказал на конференции IT-директор компании «ДНС Ритейл» Андрей Гончарук.

30.03.2020    3131    0    Goncharuk.a    9    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

На самом деле, переход рабочей жизни в онлайн обладает некоторым количеством плюсов. В частности хочется верить, что формальный контроль “отслеживаем кто сколько часов проработал, проверка, что сотрудники на месте и все чем-то заняты” заменится фактической отчетностью “по результатам”.

23.03.2020    4759    0    MariaTemchina    24    

Конфигурация: Автоматизация работы ИТ-отдела Промо

Финансовый учет и бюджетирование (FRP) Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Управление персоналом (HRM) Управление холдингом (CPM) Учет ОС и НМА Учет рабочего времени Управленческий учет (прочее) v77::ОУ ИТ-компания УУ Бесплатно (free)

Конфигурация предназначенная для автоматизации работы ИТ-отдела. На данный момент реализованы блоки учета бюджетирования, оборудования, кадровый учет, учет расходных материалов и программного обеспечения и т.д. Программный комплекс "Аристотель" предназначен для автоматизации деятельности подразделений информационных технологий, и ориентирован в первую очередь на руководителей ИТ–подразделений малого и среднего бизнеса, но также может использоваться для решения определенных задач и в рамках более крупных организаций. На основе ролей для каждого сотрудника, как ИТ–подразделения так и внешнего бизнес-подразделения организуется полноценное рабочее место со своим уровнем доступа. Програмный комплекс построен на широко распространенной платформе 1С:Предприятие.

30000 руб.

18.02.2008    49919    9    232    

От стажера до эксперта: развиваем команду разработчиков

Автоматизация ИТ-компании Бесплатно (free)

Большинство руководителей компаний понимают, что сотрудников надо обучать и развивать, но как это делать, плохо себе представляют. Как организован процесс обучения и развития разработчиков 1С в компании ФТО, на конференции Infostart Event 2019 Inception рассказал Виталий Онянов.

20.03.2020    5325    0    Tavalik    17    

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

Управление командой Бесплатно (free)

Успешный проект – это всегда сочетание нескольких составляющих. Но особенно важно, чтобы работники и руководитель компании были заинтересованы в изменениях. Как бороться с недовольством и скепсисом, возникающими у персонала и руководства, рассказала консультант по проектному и процессному управлению студии креативного консалтинга «Не просто ИДЕЯ» Ирина Шишкина.

13.03.2020    2005    0    user596192_shiiisha    0    

Программные роботы и реальная польза от RPA. Живые кейсы

Автоматизация ИТ-компании Россия Бесплатно (free)

В этой статье мы покажем, кому и как конкретно внедрение RPA поможет на примерах типовых задач в системе 1С, которые боты могут автоматизировать. Применение RPA технологии не ограничивается определенными областями и может быть полезно предприятиям во всех сферах бизнеса, где обработка данных должна быть быстрой и безошибочной.

06.12.2019    4933    0    bolefirenko    55    

Бесплатный GPS-трекинг Промо

Интеграция Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени Бесплатно (free)

Современные технологии и возможности становятся все более доступными для широких масс и повсеместно используемыми, как для частного лица, так и для мелкого и среднего бизнеса. Так и GPS-трекинг (отслеживание в реальном времени на карте местоположения водителей, курьеров, монтажных бригад, торговых представителей, детей, собак и т.п., а также просмотр статистики по их передвижениям и остановкам), становится сейчас все более востребованным сервисом, как для домашних условий, так и для предприятия. И, если крупные фирмы (например, транспортные предприятия) подписав договора с коммерческими сервисами, оплачивая своевременно счета за устройства и абонплату, эту проблему для себя решили, то это скорее подходит для крупных корпоративных клиентов. Что делать нам, простым смертным или небольшой фирме с несколькими водителями, например? Какие есть простые, надежные и недорогие решения?

05.01.2013    44964    0    venger    19    

Эмоциональный интеллект в управлении ИТ-командами

Управление персоналом (HRM) Автоматизация ИТ-компании Бесплатно (free)

Эмоциональный интеллект, как явление и направление, начали изучать сравнительно недавно – около 30 лет назад. Но за это время появилось уже немало знаний, которые можно и нужно использовать в управлении ИТ-командами. Как это сделать, участникам конференции рассказала консультант студии креативного консалтинга «Не просто ИДЕЯ» Ирина Шишкина.

18.11.2019    3467    0    user596192_shiiisha    7    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    6800    0    user826155    11    

Как найти «кнопку ВКЛ» у инженера, и всегда ли надо ее искать 

Управление персоналом (HRM) Личная эффективность Управление командой Россия Бесплатно (free)

Александр Орлов – управляющий партнер группы проектов Стратоплан, тренер школы менеджеров Стратоплан по работе с людьми и управленческим навыкам. На конференции Infostart Event 2018 Education Александр не только прочел доклад, но и провел мастер-класс. Мы перевели его в текстовый формат и делимся с участниками нашего сообщества. Ссылка на видеозапись мастер-класса – в конце текста.

23.10.2019    4192    0    user1069584    1    

Удаленные сотрудники: учет и систематизация работы

Управление проектом Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени УУ Бесплатно (free)

Многие компании на регулярной основе привлекают удаленных сотрудников, но результатами их работы большинство недовольны. Почему фрилансеры «кидают» заказчиков, как контролировать их работу, чтобы задачи выполнялись качественно и в срок, и как в целом настроить эффективные и взаимовыгодные отношения с удаленными работниками, рассказал участникам конференции ведущий программист 1С компании МоскоуСофт Сергей Сорокин.

14.08.2019    4563    0    primat    23    

Автоматизация для "полевых" сотрудников (тех, кто не работает в офисе)

Управление бизнес-процессами (BPM) Учет рабочего времени Учет рабочего времени v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса УУ Бесплатно (free)

Статья о том, как подходить к автоматизации процессов, где должны действовать сотрудники «в поле» - торговые представители, сервис-инженеры и т.д. На что стоит обратить внимание для таких видов бизнес-процессов

24.01.2018    14693    0    siddy    0    

Одна из причин медленной работы табеля (ЗУП 2.5, клиент-сервер, MS SQL Server)

Практика программирования Статистика базы данных Производительность и оптимизация (HighLoad) Учет рабочего времени Учет рабочего времени v8 ЗУП2.5 Россия Бесплатно (free)

В форме типового документа "Табель учета рабочего времени" было обнаружено не совсем очевидное и довольно узкое место, заметно влияющее на скорость интерактивной работы с ячейками табеля.

19.01.2016    22419    0    KAPACEB.AA    16    

Контроль рабочего времени - синхронизация СКУД LYRIX с базами 1С: ЗУП

Практика программирования Учет рабочего времени Учет рабочего времени v8 ЗУП2.5 Россия УУ Бесплатно (free)

Часто бывает необходимо анализировать не просто данные с считывателей карт прохода в офис, но анализировать в режиме сопоставления с кадровыми данными 1С: ЗУП. Актуальна также задача учета причин отсутствия и их визирования начальниками отделов. Существует простое решение на веб-клиенте 1с, с помощью объекта ВнешниеИсточникиДанных. Однако оно не обладает гибкостью - под каждые новые базы нужна перенастройка. По представленному описанию решение может быть легко воспроизведено для любых источников данных.

12.12.2014    12602    0    nano1c    13    

Общие принципы формирования графика производства в новом решении "1С: ERP Управление предприятием 2.0"

Управление бизнес-процессами (BPM) Бухгалтерский учет Финансовый учет и бюджетирование (FRP) Учет рабочего времени Финансовый учет и бюджетирование (FRP) Учет рабочего времени v8 ERP2 УУ Бесплатно (free)

Во второй статье, входящей в серию материалов, посвященных модулю производственного планирования в новом решении "1С:ERP Управление предприятием 2.0", рассматриваются особенности настройки графиков производства, в том числе интервалы планирования, расчет графика производства на верхнем уровне и выполнение графика на нижнем уровне.

21.07.2014    29035    0    itrp2013    2    

«Тайм-менеджер по помидорам» - эффективная организация рабочего времени.

Учет рабочего времени Личная эффективность Учет рабочего времени Россия Бесплатно (free)

Приходилось ли вам, взглянув на часы, с ужасом видеть, что день подходит к концу, а работы еще невпроворот. «Тайм-менеджер по помидорам» - простая система концентрации, помогающая эффективно организовать свой рабочий день.

30.07.2013    35724    0    LexSeIch    49    

Ой, инвентаризация, чтоб её…

Бухгалтерский учет Розничная торговля Учет рабочего времени Учет ТМЦ Розничная торговля Учет рабочего времени Учет ТМЦ Розничная и сетевая торговля (FMCG) Россия Бесплатно (free)

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

06.05.2013    13338    0    AlexanderEkb    34    

Работа с PerCo своими силами

Внешние источники данных Учет рабочего времени Учет рабочего времени v8 1cv8.cf Россия Бесплатно (free)

Сейчас предлагаются различные готовые модули для работы PerCo с 1С. Но не всегда решение простых задач требует установки дополнительного модуля. Рассмотрим подключение для создания и изменения карт сотрудников.

03.10.2012    30595    0    Nas'ka    24    

Расчет сверхурочной работы

Зарплата Учет рабочего времени Бухгалтерские Зарплата Учет рабочего времени v77::Расчет 1С7:ЗиК 1С7:Комплекс Россия БУ Бесплатно (free)

Сверхурочной работой считается работа, производимая работником по инициативе работодателя сверх нормального числа рабочих часов за учетный период (п.1 ч.2 ст. 99 ТК РФ). Данная обработка позволяет автоматически по итогам учетного периода (месяц, квартал, год) расчитать переработку сотрудников и расчитать им доплату за сверхурочную работу.

31.08.2011    21447    0    victuan    29    

Отчет по операторам и Табель

Управленческие Учет рабочего времени Учет рабочего времени v7.7 1cv7.md Россия УУ Бесплатно (free)

Отчеты: 1) Отчет по операторам показывает работу операторов по вводу документов ЗаявкаПокупателя 2) Табель учета рабочего времени заполняется автоматически на каждого пользователя 1С на основании журнала регистрации.

19.06.2010    13369    0    ManyakRus    8    

v7.7 ЗиК. Невыходы списку сотрудников

Обработка документов Зарплата Управление персоналом (HRM) Учет рабочего времени Зарплата Управление персоналом (HRM) Учет рабочего времени v77::Расчет 1С7:ЗиК Россия БУ Бесплатно (free)

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

10.03.2010    6501    0    vladb50@mail.ru    2    

Выгрузка данных в MS-Project

Загрузка и выгрузка в Excel Внешние источники данных Учет рабочего времени Учет рабочего времени v8 1cv8.cf Бесплатно (free)

У многих есть вариации на тему учета рабочего времени (своего или своих подчиненных) в различных конфигурациях. И почти ничто не предоставляет таких возможностей управления задачами внутри проекта, как MS-Project. Так давайте совместим все это.

29.12.2009    13877    0    dolter    3    

Табель Форма Т-13 для Бух.7.7

Универсальные печатные формы Бухгалтерские Зарплата Управление персоналом (HRM) Учет рабочего времени Зарплата Управление персоналом (HRM) Учет рабочего времени v77::БУ 1С7:Бух БУ Бесплатно (free)

Выкладываю по просьбе бухгалтеров Внешняя форма Табеля учета рабочего времени Т-13 для 1С: Бухгалтерия 7.7

07.12.2009    16366    0    Доня    14    

Отчет по очередным отпускам для ЗиК 7.7

Бухгалтерские Учет рабочего времени Учет рабочего времени v77::Расчет 1С7:ЗиК Россия Бесплатно (free)

Отчет формируется после проведения документа "Приказ по отпуску". За произвольный период.

28.10.2009    8791    0    ElenaV    6    

Учет отработанного времени

Зарплата Учет рабочего времени Бухгалтерские Зарплата Учет рабочего времени v77::Расчет 1С7:ЗиК Россия Бесплатно (free)

Отчет для типовой конфигурации "1С:Зарплата+Кадры показывает помесячно количество отработанных часов из табеля, а также переработку сверх норм.

28.10.2009    12227    0    Nicholas    11    

Работаем с пропускной системой Perco прямо из 1С

Внешние источники данных Разработка внешних компонент Учет рабочего времени Учет рабочего времени v7.7 1cv7.md Бесплатно (free)

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

20.10.2009    22082    0    ge_ni    10    

Приказ о работе в выходные дни

Печатные формы документов Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени v8 ЗУП2.5 Россия Бесплатно (free)

Пример внешней печатной формы для документов "Оплата праздничных и выходных дней организаций" в ЗУП 2.5.

07.10.2009    29002    0    daulberg    13    

Заполнение табличной части документа "Оплаты праздничных и выходных дней" работавшими в эти дни

Обработка документов Зарплата Учет рабочего времени Зарплата Учет рабочего времени v8 ЗУП2.5 Россия БУ Бесплатно (free)

Подключаемая обработка заполнения табличной части документа "Оплаты праздничных и выходных дней" 1. по всем работавшим в праздничные и выходные дни; 2. По подразделению; 3. По одному сотруднику

21.05.2009    15048    0    WiseSnake    22    

В помощь кадровикам, работающим на ЗиК 7.7

Практика программирования Учет рабочего времени Учет рабочего времени v7.7 1С7:ЗиК Россия БУ УУ Бесплатно (free)

В помощь кадровикам, работающим на ЗиК 7.7 при оформлении документов прием на работу и кадровое перемещение

07.04.2009    7740    0    @lex    1    

Табель учета использования рабочего времени и начисления заработка. 1С ЗиК 7.7 Беларусь

Бухгалтерские Управленческие Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени v77::БУ 1С7:ЗиК Сельское хозяйство и рыболовство Беларусь Бесплатно (free)

Табель учета использования рабочего времени и начисления заработка при повременной оплате труда формы ТО-2 и формы 501-АПК для сельских хозяйств РБ.

09.01.2009    12057    0    bonya_by    2    

Сменный табель для конфигурации "Камин:Расчет зарплаты 2.0"

Универсальные печатные формы Бухгалтерские Зарплата Учет рабочего времени Зарплата Учет рабочего времени v77::БУ 1cv7.md БУ Бесплатно (free)

Тем, кто хочет попробовать альтернативный табельный учет в конфигурации "Камин: Расчет зарплаты 2.0" - милости просим.

19.11.2008    8400    0    sergling    1    

Печатная форма Табеля урочного времени

Печатные формы документов Учет рабочего времени Учет рабочего времени v77::Расчет 1С7:ЗиК Россия БУ Бесплатно (free)

Подготовка печатных форм Табелей урочного времени с включением введенных в ЗиК документов отклонений.

10.09.2008    8350    0    aka AMIGO    14    

Учет рабочего времени

Учет рабочего времени Управленческий учет (прочее) v8 Россия Бесплатно (free)

Насмотрелся на классные конфиги, которые тут выкладывают люди, и решил выложить свою :) Упрощенная система учета рабочего времени специалистов ИТ-отдела. Ничего лишнего - задания, журнал заданий, отчет.

14.08.2008    8161    0    Krat0S    12