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

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

Анализ и управление - Управление командой

Для развития продукта важен продуктовый подход и владелец продукта, который знает, что надо сделать в первую очередь, а от чего пока стоит отказаться. Почему это базовое требование, и чем продуктовый подход в 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 в Москве.

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Masik_by 16.03.23 07:45 Сейчас в теме
Добрый день.
Спасибо, что поделились опытом.
Очень понравилась статья, все просто, прозрачно и понятно описано.
Оставьте свое сообщение

См. также

Что такое «золотая» команда автоматизации?

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

Крупные компании отказываются от внедрения продуктов третьими лицами и переходят на собственные команды. Как позиционировать команду автоматизации в структуре компании, чтобы эффективно решать задачи бизнеса и приносить ему ценность, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель департамента разработки и эксплуатации учетных систем компании «Самокат» Иван Баринов.

сегодня в 16:48    85    izidavld    0    

1

Распределенная команда разработчиков. Как ей эффективно управлять?

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

На конференции Infostart Event 2021 Post-Apocalypse директор ресурсного центра Programming Store Алексей Петухов поделился пятью правилами, которые позволят эффективно управлять распределенной командой разработчиков, и показал методики и инструменты, помогающие довести проект до запуска.

22.03.2023    207    Programming Store    0    

3

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

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

Проблемы с доверием, отсутствие совместных ценностей и неграмотное распределение обязанностей между участниками команды могут завалить результат проекта. Кроме этого, важно прислушиваться к мнению стейкхолдеров и не вступать в политические игры заказчика. О том, как распознать типовые ситуации, которые могут завалить проект, и как использовать этап развития команды на благо, на конференции Infostart Event 2021 Post-Apocalypse рассказали основатель школы управления изменениями Марианна Крель и ее коллега Павел Потеев.

20.03.2023    560    marianna.krell    1    

5

Гибкий подход в управлении командой проекта автоматизации для крупных компаний

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

Как организовать работу, когда на проекте несколько подрядчиков? И какие инструменты помогут организовать процесс, чтобы сдать все задачи в срок? Об этом на конференции Infostart Event 2021 Post-Apocalypse рассказал генеральный директор компании ИТАН Александр Рыжов.

17.03.2023    784    Alexandr_Ryzhov    2    

16

Токсичные сотрудники в команде проекта

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

В любой команде может обнаружиться человек, который портит настроение и мотивацию всех остальных сотрудников. О том, как вычислить токсиков в вашей команде, чем их вылечить, и как от них избавиться, если они не лечатся, на Infostart Event 2021 Moscow Premiere рассказала Ирина Шишкина.

16.03.2023    744    user596192_shiiisha    10    

5

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

СПАРК помогает предотвратить мошенничество со стороны компаний и предпринимателей, благодаря актуальным сведениям о компаниях и системе выявления факторов риска.Сервис позволяет управлять налоговыми рисками и комплексно оценивать благонадежность контрагентов.

Доверие как инструмент мотивации в гонке зарплат

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

На конференции Infostart Event 2021 Post-Apocalypse руководитель проектов и бизнес-аналитик Павел Ступко поделился 15 привычками, которые помогают увеличить уровень доверия в компании. Он рассказал, как доверие помогает нанимать лучших людей в команду, и почему не стоит торопиться строить бирюзовую организацию.

15.03.2023    411    user920251    4    

4

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Управление командой Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    1611    andironenko    2    

23

Перестать заниматься микроменеджментом и начать работать

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

Менеджеры привыкли, что нужно постоянно контролировать сотрудников, чтобы все вышло качественно и в срок. Сначала они назначают кучу совещаний, затем запрещают отвлекаться и не отпускают на удаленку. Такой микроменеджмент ведет сотрудников к выгоранию и отсутствию мотивации. На Infostart Event 2021 Post-Apocalypse Артур Дементьев рассказал, как перестать заниматься микроменеджментом так, чтобы ничего в компании не развалилось.

18.01.2023    1301    demntad    5    

12

Тимлид или Руководитель группы разработки?

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

Те, кто хоть как-то связан с разработкой, наверняка знают определение слова team lead (тим лид). Но что есть team lead по сути – это технический лидер, менеджер команды или играющий тренер? Какие задачи он должен решать? Тимлид 1С в компании «Авито» Алексей Климашенко рассказал, в чем отличие тимлида от руководителя группы разработки, и уместна ли в сфере 1С позиция team lead'а в классическом понимании.

08.12.2022    2041    klimat12    2    

11

Danger! High voltage! Предупреждение выгорания в команде

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

Выгорание – один из факторов, который мешает завершить проект качественно и в срок. Руководитель проектов с многолетним опытом Ирина Шишкина рассказала, как выявить выгорание в команде, как предупредить и не спровоцировать это состояние у участников, и какие инструменты помогут сохранить психологическое здоровье в команде в период кризиса.

23.11.2022    876    user596192_shiiisha    0    

3

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

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

3 500 рублей

Плоская структура или какого цвета наша команда

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

Мария Бондаренко на конференции Infostart Event 2021 Post-Apocalypse рассказала о том, как выстраивать процесс работы в команде, в чем преимущества и недостатки плоской структуры, и можно ли мечтать о бирюзовом цвете для своей организации.

21.11.2022    882    mbondarenko    1    

5

Фишки нематериальной мотивации, которые работают в «Софт-Юнион»

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

Генеральный директор «Софт-Юнион» Владислав Епанчинцев рассказал, как сохраняет заряженную на работу обстановку среди сотрудников. Все начиналось с безобидных рейтингов, но теперь в компании снимают челленджи, выдают флажки за глупости, а на бейджиках носят наклейки со ртами. На Infostart Event 2021 Post-Apocalypse он показал, какие виды мотивации бывают, и как их использовать, чтобы поддерживать драйв в компании.

16.11.2022    1117    vlad.e    10    

5

Делегировать 100% полномочий и умереть

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

Dev unit lead компании Skyeng Константин Волков на конференции Infostart Event 2021 Post-Apocalypse рассказал, как делегировать сотрудникам 100% полномочий, и к чему это может привести. Он поделился советами по мотивации команды и сравнил управление командой с управлением самолетом.

07.11.2022    994    user1544625    0    

6

Командообразование – светлая и темная сторона силы

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

Общепринято считается, что команда должна быть сплоченной, а коллектив – дружным. Но у сплоченного и дружного коллектива есть и темная сторона, потому что без критики и новизны команда деградирует. О том, как этого не допустить, на конференции Infostart Event 2021 Post-Apocalypse рассказал Dev unit lead компании Skyeng Константин Волков.

24.10.2022    962    user1544625    1    

6

Аналитик 1С: так ли он нужен?

Анализ и проектирование ИТ-систем Управление командой Внедрение ИТ-системы Россия Бесплатно (free)

Не все клиенты понимают, зачем на проекте внедрения или сопровождения 1С аналитики. Разве с поставленными задачами не справится хороший программист? Давайте разбираться вместе с экспертами компании «Внедренцы и Программисты».

13.10.2022    2502    ystetsenko    16    

5

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Внедрение ИТ-системы Управление проектом Управление командой Управление ИТ-подразделением Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    5390    biimmap    70    

51

Как искать программистов 1С и стоит ли вообще это делать?

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

Найти программиста 1С всегда непросто, а сегодня особенно: рынок перегрет. Что делать собственнику или руководителю компании, в которой намечается 1С проект? Рассмотрим рабочие способы поиска специалистов вместе с техническим директором «Внедренцев и Программистов» — Анастасией Синяковой.

23.08.2022    1298    ystetsenko    4    

3

Как превратить бизнес-заказчиков и разработчиков в единую команду?

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

Один из подходов, который помогает найти с бизнес-заказчиком общий язык и организовать сотрудничество – это использование принципа бережливой разработки (Lean Development). На митапе «Сбор требований и составление ТЗ» директор по проектам Инфостарта Мария Темчина рассказала, как с помощью этого принципа наладить взаимодействие с заказчиком, и показала практические инструменты, которые удобно применять при сборе требований.

26.05.2022    2576    MariaTemchina    0    

8

Компетенции руководителя проектов

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

На конференции Infostart Event 2021 Post-Apocalypse выступила HR компании IT Capital Анна Степанян. Она предостерегла от ошибок при выборе руководителя проектов и рассказала о том, как выстроить свою систему отбора кандидатов на роль человека, которому можно доверить команду и репутацию всей компании.

17.05.2022    1490    Охотница за головами    0    

8

Работа с 1С:Аналитика Промо

Онлайн-курс предусматривает изучение возможностей системы “1С:Аналитика”, которая работает как составная часть платформы “1С:Предприятие” и обеспечивает оперативный просмотр и анализ необходимых данных.

4500 рублей

Роль и задачи аналитика в проектной команде при внедрении 1С

Управление командой Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Типовые продукты фирмы «1С» становятся все более гибкими, и функция разработки или изменения для них очень часто вообще не требуется или требуется точечно, поэтому для подобных проектов появился отдельный специалист – аналитик 1С. Какие у него задачи, и чем он отличается от системного аналитика и бизнес-аналитика, рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

19.01.2022    10022    denisgalimoff    8    

21

Подбор и организация работы команды на проекте внедрения 1С. Создание команды проекта

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

Работа в команде на проекте очень сильно отличается от самостоятельной работы специалиста и требует определенных навыков и личных качеств каждого из членов команды. Основное отличие командной работы от самостоятельной – это умение и готовность нести коллективную ответственность за результат. Давайте представим себе соревнования по бегу, где нужно определить самого быстрого. В этом случае каждый бегун постарается вложиться в скорость и добежать до финиша как можно быстрее на полной выкладке сил. А теперь давайте представим соревнование между командами, в которых определяется команда, добежавшая до финиша первой и при этом зачёт идёт по последнему, какую стратегию в этом случае стоит избрать каждому бегуну?

30.11.2021    1558    Koder_Line    3    

7

"Пасти котов распределенно" – 7 важных приемов для менеджера проектов в управлении распределенной командой, особенно если раньше она такой не была

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

Сооснователь и вице-президент Петербургского отделения PMI, тренер по управлению проектами Иван Селиховкин выступил на митапе «Инструментарий руководителя проектов». В ходе доклада Иван поделился неочевидными приемами работы с распределенной командой: как личными, так и управленческими.

22.11.2021    2590    Selikhovkin    1    

11

Должностные инструкции в 1С

Управление командой Кадровый учет Конфигурации 1cv8 Бесплатно (free)

В данной статье будут рассмотрены должностные инструкции для разработчика 1С 8. Будут определены общие положения, должностные обязанности программиста, а также его права. Кроме того, будут определены пункты, по которым он несёт ответственность.

01.09.2021    2807    Koder_Line    4    

1

Собеседование программиста 1С

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

Собеседование на должность программиста 1С - это стресс или переговоры? Рассмотрим цели и задачи собеседования; подходы, применяемые для собеседования программистов; подготовку к собеседованию.

16.03.2021    5692    maraton1185    3    

5

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Хакатон Цифровой прорыв 2020 (Северо-Западный IT-ХАБ) глазами участника

Управление командой Мотивация, лидерство и личная эффективность Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В минувшие выходные, с 13 по 15 ноября 2020 года, в Санкт-Петербурге прошел региональный полуфинал СЗФО всероссийского конкурса «Цифровой прорыв» – флагманского проекта президентской платформы «Россия – страна возможностей». Делюсь с сообществом взглядом на него со стороны участника.

17.11.2020    1498    capitan    5    

6

Управление в стиле Agile. Как создать самоуправляемую команду в ИТ проекте

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

Про Agile только на конференциях Инфостарта сказано уже так много, что, кажется, сложно кого-то удивить. Но руководителю компании Rodionov consulting Денису Родионову это удалось, потому что он в своем докладе на Infostart Event 2019 Inception рассказал не только сухую теорию, но и примеры из собственной практики.

25.09.2020    4064    denislan    0    

5

Кто такой самозанятый, и стоит ли им становиться

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

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

17.09.2020    6839    akomandin    53    

27

Список вопросов для собеседования кандидатов на должность "Программист 1С"

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

Я стал тимлидом. Через некоторое время нужно было расширять штат программистов. Передо мной встал вопрос «Как отбирать кандидатов?» 

07.08.2020    41137    coollerinc    84    

118

Управление персоналом через систему ценностей

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

Ценности – очень эффективный механизм для управления персоналом. О том, как сформулировать ценности компании и прийти через них к согласию с коллективом, в своем докладе на конференции Infostart Event 2019 Inception рассказал Антон Солодков, директор компании Ант-Хилл.

31.07.2020    2548    user607296_solodkov    4    

8

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Как эффективно управлять командой удаленных программистов 1С

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

Дистанционная работа становится все популярнее, и многие компании задумываются о том, что, возможно, стоит попробовать работать с разработчиками на удаленке. Но чтобы такое сотрудничество было эффективным, придется не только контролировать код на выходе. Нужно еще научиться взаимодействовать в условиях разных часовых поясов, вести учет отработанного времени, уметь удержать и заинтересовать работника. О том, как эффективно управлять удаленной командой высококвалифицированных программистов 1С, на конференции Infostart Event 2019 Inception рассказал руководитель компании «Крон» Ранис Усманов.

27.07.2020    11922    Ranis1286    50    

41

Развитие команды проекта и командообразование (тимбилдинг). Курс по управлению проектами, часть 31

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

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

10.04.2020    3281    Selikhovkin    0    

4

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

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

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

13.03.2020    4068    user596192_shiiisha    0    

5

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

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

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

11.11.2019    8983    user826155    11    

35

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

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

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

23.10.2019    5567    user1069584    1    

10

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Scrum-команда: рассказываем, кто все эти люди

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

Scrum – методология, которую стремится внедрить практически каждая небольшая команда, создающая программное обеспечение. Да и в других отраслях она прижилась благодаря логичности, универсальности и эффективности. Но новички, которые попадают в scrum-команду, часто не совсем понимают, что происходит, и какие функции у каждого участника. Разбираемся, какие роли могут быть в scrum-команде.

10.12.2018    6057    user1015646    8    

7

Построение высокоэффективной Agile-команды

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

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    9675    askhatu    15    

37

Система мотивации команд разработки и внедрения систем управления производством

Управление персоналом (HRM) Внедрение ИТ-системы Управление командой Управленческий учет Бесплатно (free)

Вопросы мотивации каждая компания решает по-своему. Руководитель проектов по автоматизации Артем Шамсутдинов рассказал о том, какую систему мотивации выбрали для себя в компании.

30.07.2018    7379    sm.artem    3    

14

Ошибки команд или как стать лучше

Управление командой 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

12.08.2015    24758    Stepa86    17    

184

Тест Белбина … и как «ЕГО» понимают …

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

Рэймонд Мередит Белбин (Belbin) (р. 1926) Британский психолог, выпускник Кембриджа. Известен как автор методики формирования эффективных управленческих команд. Тест Белбина - не тест на совместимость участников группы и он не решает задач профессиональной ориентации. Так ЧТО же это такое – тест Белбина …?

1 стартмани

28.07.2009    42901    Шёпот теней    55    

22