Это прям печальный кейс. Видел когда новый продукт саботируют рядовые сотрудники. Но хуже всего, если этим занимаются топы. Тогда вообще никакого смысла в системе нет.
И как понимаю из вашего комментария, там еще куча проблем с коммуникацией от руководителя. Неумение ставить задачи, строить процессы. Если это собственник, то тут уже вряд ли что поможет :-)
Тоже соглашусь. CRM может отлично бустануть бизнес, но на определенном этапе. Я довольно давно работаю с подобными системами и понимаю, что бывают разные случаи. Некоторые хотят внедрить новую систему просто потому, что “где-то читали и нам тоже нужно”. Или бывает “внедрение для внедрения” просто как элемент освоения бюджета или внутренней политики. Да много разного бывает.
Но, если бизнес понимает, что он хочет решить, при помощи нового продукта, то могут получиться отличные результаты. Так можно структурировать процессы и избавиться от хаоса или ускорить процессы. Правда, у меня больше опыт взаимодействия с крупными заказчиками. И там с этим немного проще.
Главное ставить цели и строить путь к их достижению, если вы хотите внедрить такой продукт.
А на счет того, что нет решения, в котором можно было бы решать все задачи, не могу согласиться. Рекламировать никого не буду, но есть продукты, которые могут закрыть широкий спектр потребностей. С гибкой настройкой, раздачей прав, созданием своих разделов форм, дашбордов и т.д. и т.п. Да, такое решение будет дороже нишевого, но дешевле чем если поднимать его с нуля.
Прежде чем меня закидают помидорами, стоит оговориться, что я пишу скорее про сегмент среднего или крупного бизнеса. Малый тоже может себе позволить подобные решения, но для этого ему понадобится хорошо понимать свои процессы или иметь хорошего аналитика в штате. Цена внедрения для малого бизнеса может оказаться неподъемной.
Плюсую автору. Мы сейчас тестируем NextCloud. Подбираем набор плагинов. Можно сказать, формируем экосистему, под свои нужды. Но у них очень не удобный маркетплейс. Пробовали и другие аналоги, но пока не получается закрыть потребности комплексно то, чем мы регулярно пользовались в тимс.
Есть и позитивные моменты для нас, как для разработчиков. Открывается много возможностей практического применения чужого опыта. Как редактирование файлов в онлиофис в некстклауд. Можно понаблюдать как это взлетает у коллег по рынку.
Жаль, что пока не все поставщики понимают, что тимс не только про то чтобы чатиться, звонить или рисовать доски. А еще и совместное редактирование документов, версионность файлов. Да и те же созвоны с возможностью записей, выгрузкой в облако и т.д. и т.п. Просто часто вижу рекламу “аналогов тимс”, в которой упор идет на чаты и звонки. Без всех остальных возможностей.
Опять же это будет зависеть от целей заказчика. От того как он понимает проект. Мы со своей стороны приложим все усилия, чтобы сделать проект эффективным. И много клиентов, которые либо “с ходу” приносят свое понимание процессов, понимают цели проекта и действительно хотят создать ценность. Либо во время работы над проектом формируют это понимание. И эти проекты потом радуют. Таких клиентов также много. С ними приятно работать.
Возвращаясь к кейсу, это может быть не то, что мы все представляем под процессом продаж, особенно продаж на потоке. Такая система будет учитывать особенности бизнеса.
Да и про “научить” я нигде не говорил. Про то, что подготовить команду клиента, внедрять продукт постепенно, а не “с двух ног”.
Но я понимаю чем вызван негатив. Сейчас много тех кто говорит или пишет как “истина в последней инстанции”. По типу “мы лучше знаем как должен работать бизнес клиента или заказанный им продукт”. Иногда да, опыт может подсказывать верные решения. Но это всегда совместное творчество. Когда мы хотим сделать так, чтобы клиент получил рост своих метрик эффективности, а мы долгосрочные финансовые отношения с клиентом.
У нас нет шаблонов “как надо”. Мы пилим проект под нужды и требования клиента. И готовы учитывать такие нюансы, как игру в гольф или походы в баню. :)) Спасибо за содержательный комментарий.
В статье я и не думал о глубине темы. Скорее описал свое личное восприятие.
Я с вами согласен, что можно было постараться раскрыть тему прийти к каким-то выводам. Просто хабр, для меня, выполняет скорее терапевтическую функцию. Иногда хочется поделиться своими мыслями и посмотреть на то, как на эти мысли или описанные ситуации реагируют другие участники комьюнити. Многие пишут классные и полезные мысли в комментах. Это здорово!
А так да, прочитал и призадумался. С одной стороны все верно, но если детализировать, то можно заметить ряд моментов, которые также стоит учитывать.
1. Пример с Open AI мне видится немного утрированным. То есть, теоретически можно было бы вообразить, что кому-то потребуется доска, на которой будет процесс генерации каждого промта. Но вероятность того, что такой проект кто-то захочет реализовать, тем более при помощи стороннего подрядчика, стремится к нулю.
Все же от количества процессов, их глубины и сложности также зависит и сам проект. Возможность возникновения потребности в проекте и поиск способов его реализации.
В статье я говорю о процессах, где есть четкие роли, задачи у этих ролей и этапы прохождения этих задач. Не миллионы промтов, а десятки, может сотни действий в день. Более приземленный проект.
Если утрировать, то можно придумать много примеров. Они будут нежизнеспособны, не применимы на практике. Но могут доказывать точку зрения. Мне приятно, что вы постарались изложить свою точку зрения и я бы предложил подискутировать более предметно.
Например, ваш второй кейс. Да, в нем есть ряд отхождений от классического процесса продаж. Но они также могут быть учтены. Мы можем включать или не включать сами эти действия в процесс. Это может быть что-то универсальное, например “Стадия переговоров”. Внутри этой стадии могут быть комментарии: “Клиент любит ходить в баню по субботам и такое-то пиво”. Эти данные мы можем положить в карточку клиента и учитывать в будущем. Ведь сейлз может уйти, а новому сейлзу придется заново выстраивать отношения с этим клиентом.
И это нас приводит к этапам построения процесса. От касания с клиентом и заведения его карточки в базу. И дальше по этапам продажи (индивидуально для данной компании: переговоры, отправлено КП, согласование условий и так вплоть до успеха или провала. Также мы можем ставить задачи в этой системе. Сводить данные по успехам и провалам. Какие менеджеры остаются на “стадии переговоров” и просто ходят в баню с клиентом, но не приносят никаких продаж. И т.д. и т.п.
Здесь речь не идет про то, чтобы всех поставить “к ногтю” и сломать то, что не работает. Сделать эффективнее - да. Понять процессы, найти их уязвимости и точки роста - безусловно.
Что вы имеете ввиду под формализацией, я понимаю. Такое тоже бывает. И зачастую этот процесс происходит на стороне клиента. Изначально цель проекта “формализовать процессы”, а по факту привести их под тот общий знаменатель, каким его видит “биг босс”. А он часто видит процессы как “да что там делать, пять минут и готов”. А это может быть что-то емкое. Вот тогда да, в таких проектах внедрение новой системы может быть неэффективно.
Но если посчитать, что проект не для освоения бюджета, каких-то личных целей менеджеров или других причин, а ориентированный именно на то, чтобы вырастить эффективность работы, то основным критерием успеха проекта будет упрощение работы сотрудников и прозрачное понимание процессов. Возможность оценить те же пресловутые точки роста, моменты провалов и т.п.
По процессам не являющимся ключевой компетенцией (уборка, кофе и т.п.). Ну, мы про них просто не говорим сейчас. Пока не встречал проект, в котором это были бы ключевые этапы процесса. Но если бы такой проект пришел, то можно было бы и его сделать. Почему нет?
Клиент хочет реализовать проект. Он видит в нем ценность. Мы соберем требования, проанализируем процесс, предложим решения. Подготовим документацию, утвердим и реализуем проект.
Надо ли автоматизировать процессы или лучше посадить студента со знанием питона? Да, все индивидуально. Справится студент с питоном, когда в компании много отделов и ролей в них, прав по записям или по операциям, пересекающиеся группы интересов, разные стадии, сегментация клиентов, проектов, есть разные активности, а сверху это все накрывается документооборотом? Маловероятно. А выдержит ли такая система нагрузку, сможет ли она масштабироваться? Тоже вряд ли.
Зааутсорсить тоже можно. Только, что вы вкладываете в это понятие? Мы вот, как внедренцы, тоже аутсорсом занимаемся. Или речь о том, чтобы зааутсорсить этапы работы, передавать рабочие документы, контакты клиентов? Мало кто бы на это согласился. Если отдать на аутсорс уборку и кофе, то да, вопросов не имею.
Должен ли бизнес знать процессы? Вопрос интересный. Зависит от уровней. Если мы говорим, должен ли гендир большого холдинга знать как конкретные сейлзы по скрипту работают? Нет конечно. Это был бы снова утрированный пример. А вот должен ли РОП знать как строятся продажи в его отделе – безусловно. Так и строится структура проекта. Кто-то ответственный от компании собирает требования от стейкхолдеров (РОПы, РОМы, РП, PR, менеджеры и т.д.). Каждый на своем месте. Каждый ответственен за свой “кусочек пирога”. Потом этот человек все сводит воедино и передает нам. Мы на всех этапах стараемся ему помочь.
Были ли идеальные проекты, когда получилось сразу реализовать проект, который закрывал бы 100% потребностей? Возможно. Но я не встречал такие. Круто, если получается закрыть 60-70%, потом будут доработки и оптимизация. Уточнение требований. Особенно когда РОП посмотрит на готовый проект и поймет что ему еще чего-то не хватает, оно жизненно необходимо, а он просто об этом забыл, при составлении требований. Такое постоянно происходит.
Должен ли знать сотрудник процессы своей компании? Нет, не должен. Но должен быть наделен полномочиями, которые позволят эти процессы “снять”, систематизировать и сделать ту работу, которая от него требуется.
Да и моя статья не столько про незнание процессов, сколько про обычную лень. Когда клиент не хочет собирать процессы, когда тех дизайн подписывается “не глядя”, а перед сдачей проекта выясняется, что “это не то, что нам надо”. Да и про много чего еще. Просто это проще объединить про “незнание процессов”. Потому что и внутри своих отделов, подразделений клиенты часто не знают что происходит.
Еще раз спасибо за комментарий! Я только начинаю писать. И тема, для меня, по своему, эмоциональная. Так что “интересная тема поднята, но глубина и близко не раскрыта, увы…” – меня немного взгрустнуло. Но ваш комментарий заставил меня поразмышлять. Вот, делюсь с вами, своими размышлениями.
Но тогда вопрос. Как “врываться к исполнителям”, если это проект клиента и он сам дает выделенного менеджера?
То есть для нас заказчик выглядит как определенный менеджер или некий комитет, через который решаются все вопросы. У нас есть регламенты и документация, которые позволяют лучше вникнуть в процессы клиента и проработать все проекты “на берегу”. Аналитики, как могут, вытягивают из клиента данные по процессам. Но этот набор регламентов и документов, которые согласуются с клиентом, иногда не гарантирует точного понимания процессов клиента.
В какой-то момент вообще, может оказаться, что проект, который создавался на протяжении полугода, совсем нерелевантен целям клиента. Мы совместно с клиентом начинаем копать и оказывается, что на этапе согласования представитель заказчика просто не прочитал технический дизайн, подписал его просто потому что “да что там делать?” А это проект с массой зависимостей, ролей и т.д. и т.п.
Или такой проект сваливается просто под действием внутренней политики компании клиента. Когда человек, который отвечает за внедрение, внутри компании клиента, не хочет, чтобы проект был сделан. Ему, по каким-то своим причинам, выгодно чтобы проект не был успешен. И это не будет озвучено вслух. Просто постепенно, в процессе работы, начнут происходить “странности” и чем дальше тем все “страньше и страньше”. Но это отдельная тема, по которой можно много чего рассказать. И сейчас не вижу смысла углубляться.
Еще есть nda (иногда доходит до полнейшего маразма, когда представитель клиента не может дать жизненно важную, для проекта, информацию), такие же проблемы с ИБ, саботаж на уровне пользователей проекта (рядовых сотрудников), проект, который изначально был для “освоения бюджета” и в компании никто, на самом деле, не заинтересован в его завершении, а еще интриги, скандалы, расследования. Да еще много чего бывает. Какие-то моменты реже, какие-то чаще.
Но бывает и обратная сторона. Есть клиенты, представители которых, действительно заинтересованы в успешном завершении проекта. И представители такой компании почему-то знают и процессы, и роли да и то, что не знают, быстро узнают и вносят в документацию.
Да, при этом невозможно сразу охватить все. Поэтому есть поддержка, обучение клиента и возможность “докручивания” проекта нашими силами.
Бывают такие клиенты. И их тоже не мало. Просто здесь пишу о том, что занимает больше сил и энергии. А значит и рефлексии, ей и делюсь.
Тут речь скорее не про “красивые сказки”, а про то какие внутренние цели стоят перед самой компанией и ее представителями. Какая у этих представителей компетенция, погруженность в рабочие процессы. Нужно ли такому “внутреннему внедренцу” создать видимость деятельности, заинтересован ли он в новом проекте или он получает какие-то преференции со старого решения и ему выгодно оставить “как есть”, даже если это тормозит всю компанию.
По менеджменту, да. Тут проблема не только в том, что учат “управлять чем угодно”, а еще и в том, что многие “эффективные менеджеры” не стремятся понимать суть процессов, механизмов своих компаний, отделов и т.п. А вместо этого, устраивают политические игры или просто пытаются “выжать” все что можно. И делается это все не для создания ценности, в том числе своей, как профессионала, а для построения имитаций.
С культурой – в самое яблочко!
Правда не всегда и не все так плохо. Есть классные менеджеры, которые понимают и свои процессы и стараются генерить ценность. С ними приятно работать. Просто те о ком мы тут с вами пишем, требуют больше трудозатрат и сил. Поэтому их кажется больше.
Согласен, но частично. Согласен с тем, что есть такие проблемы, но не согласен с какой-то обреченностью, которую, как мне кажется, уловил в вашем комментарии. Если это не так, то извините, значит показалось. Но тем не менее попробую описать то, с чего можно было бы начать решать эти проблемы. Пойду снизу вверх:
1. Про “дикое сопротивление, вплоть до увольнения”. Саботаж при введении новых систем и процессов, со стороны рядовых сотрудников, это распространенная проблема. Но благодаря этому также есть много возможностей, как повлиять на своих сотрудников.
Первое с чего стоило бы начать – узнать с чем вообще связано недовольство. Главное выделить те проблемы, которые чаще всего встречаются. Это могут быть как объективные проблемы (как “новая система/процесс увеличивают время решения задач или делают их менее удобными, чем было раньше”) или субъективные проблемы (утрировано “не нравится цвет кнопок” или просто “пофиг, что новая система автоматизирует рутинные задачи, мне в экселе было удобнее”). В идеальном мире, это можно было провести на начальных этапах работы с проектом. Но мы живем в нашем мире и хорошо бы такое исследование проводить хотя бы в процессе работы, когда доработки займут минимум времени и рисков.
С объективными проблемами, думаю, что все понятно. Собираем данные, анализируем и вносим их в роадмап проекта. Тестируем и смотрим на реакцию сотрудников.
А вот с субъективными проблемами будет сложнее. Нужно копать не в сами отзывы, а скорее в то, с чем вообще связан негатив. В то на сколько выстроены процессы (да, вы писали, что их нет и об этом также напишу ниже), как выстроена культура в команде, на квалификацию сотрудников (может они действительно могут только гугл таблицу открыть и там вручную что-то повносить). Также стоит посмотреть на то, какие есть группы сотрудников и интересы у этих групп. Я видел как хорошие проекты “падали” просто за счет того что внутри компании заказчика есть разные “политические силы”. И кому-то было просто выгодно, чтобы ничего не менялось.
Также посмотрите на то, как вы донесли до сотрудников важность новых систем и процессов. Провели ли обучение и на сколько качественным оно было. На сколько сотрудники поняли как это должно работать и как это повлияет на их работу. Улучшит ли новое их рабочий опыт?
2. “Нет бизнес процесса”. Не хочу показаться грубым, но начните выстраивать процессы. Пропишите регламенты, что, как, куда и зачем. Изучите методологии работы, которые есть. Посмотрите что вам лучше подойдет и облегчит работу сотрудников, сделает ее понятной и логичной. Только не гонитесь за модными agile и т.п. Выбирайте то что подойдет под ваш бизнес. Поймите самую суть ваших процессов, того как они должны работать, какой путь должен проходить лид или отдельная задача. Где образуются “узкие места”. Выстраивайте процессы по чуть-чуть и начните с самых важных.
Основных задач, при выстраивании процессов, я вижу две: упростить/ускорить процессы для сотрудников и сделать их прозрачными для менеджмента.
Первое позволит снять лишнее напряжение с сотрудников. Сделать так, чтобы они не тратили кучу энергии и времени на постоянное переключение между задачами/вкладками/типом действий (переключение между чем-то тоже можно рассматривать как часть процесса) и на то, чтобы постоянно разбираться в том, чего они не знают или не понимают. Чем понятнее и точнее описаны задачи, тем проще их решать и тем выше вероятность их эффективного решения.
3. По отсутствию связей и перегруженности. Это также к процессам. Если вы не понимаете как должна двигаться задача и где они агрегируются. На каком-то человеке/отделе, то вы не сможете с этим разобраться.
4. “Утеря компетенции и переход к ритуалам”. Поговорите со своими сотрудниками. Поймите с чем это связано. Почти наверняка выйдите на нерабочие или неэффективные процессы. Когда человек, который умеет круто продвигать задачи вынужден “перекладывать данные из одной эксельки в другую” или когда “эффективный менеджер оказывается просто самодуром, которому лень искать точки роста и он просто ставит задачи ради задач”. Вариантов может быть масса.
Также, если поговорить с сотрудниками, то может оказаться, что кто-то из них знает как решить проблему. Хотя бы локально, на своем месте или в отделе. Соберите и проанализируйте такие предложения, посмотрите что “бьется” с вашим видением процессов, с тем как оно работало бы эффективнее и начните внедрять это.
Также важно помнить, что процессы это не про то чтобы было удобно именно вам или не про то чтобы копировать то как “у дяди Пети”, а про то чтобы именно ваш бизнес начал работать с высоким кпд.
5. “Размывание ответственности”. У вас же каждая задача имеет исполнителя и проверяющего? Ведь так? Если да, то вы должны понимать кто и за что отвечает.
А ваши сотрудники, почему они “размазывают ответственность”? С чем это связано? Если случился провал по задаче, вы как-то его прорабатываете? Если да, то как? Завязаны ли провалы на деньги или какие-то еще формы “кнута”?
Самое главное здесь понять почему это происходит. Вопрос в сотрудниках, в организации процессов или в руководителе? В любом случае, это будут полезные данные.
SQLite - первый релиз в 2000г, последняя версия 2024г ТеХ первый релиз в 1978г, последняя 2021г К сожалению не знаю всю историю версий, но сомневаюсь, что за столько времени разрабатывались только фичи без багфиксов и оптимизации, а также что за столько времени все возможные баги были отловлены и пофикшены до попадания в очередной релиз. В целом, подобный срок достаточный для обширного сбора обратной связи и её обработки.
История с open source приложениями это история энтузиастов. В статье я писал о том, что есть люди, готовые потратить своё личное время на повышение качества разрабатываемого в рамках своей работы ПО, такие люди редкость и примерно такие же и занимаются разработкой подобных продуктов.
Также в open source специалист, как правило, не так ограничен в сроках, ведь над ним не стоит руководство, тыкающее его лицом в дату очередного релиза с набором требований, которые к этой дате в этом ПО должны быть.
Описаны полезные и применимые принципы. Не очень люблю слово agile, которое сейчас "пихают" везде и всюду, скорее как некую религию. Но то, что описано в статье, это все можно применять, а мы даже и применяем.
В результате, мы получаем высокий уровень компетенций, ответственности, самоуправления и эффективности на производстве. К минусам можно отнести то, что нужно быть готовыми к росту фот, а также к его скачкам, чаще вверх, чем вниз. Я бы назвал статью как-то типа принципы менеджмента, диктуемые рынком.
А если это разработка компании только для себя, не для продажи?
Тут стоит учитывать вопрос денег. Даже если это разработка внутреннего продукта, то она также оплачивается из бюджета компании. И такой продукт также будет иметь свои требования со стороны бизнеса.
А если бизнес, в своих требованиях, не учитывает или считает доработку качества ПО лишним, то с точки зрения описанного в статье, внутренний продукт не будет отличаться от клиентского.
Все упирается в цели бизнеса и в количество времени/средств, которые он готов вложить в разработку.
Коллега, приятно увидеть, что не только мы пришли к таким практическим гибридам. За 10 лет мы пробовали внедрять, кажется, все, что только можно.
В итоге через "кровь и пот" пришли к гибридам. Прописали свои манифесты и правила (Как правила дорожного движения - "написанные кровью").
Продолжаю читать статьи и раз за разом вижу теории. И "о чудо!" первый раз вижу команду, которая пришла к абсолютно такой же схеме работы. Разве что оценки у вас в "мерках", а у нас в числах Фибоначчи.
Буду следить за вашим опытом теперь. Удачи вам и нам - меньше страданий, больше эффекта.
На самом деле классная метрика. Единственное, что непонятно как ее трекать в “глубоком b2b”. Например для проектного внедрения. Когда продукт представляет собой платформу, которая адаптируется под требования каждого клиента.
И когда например, конечный юзер и тот кто покупает продукт, - разные люди.
То есть внедрение продукта аппрувит бизнес (ЛПР), а пользуются продуктом сотрудники компании.
Хотя, если так подумать, то с ходу можно попробовать несколько вариантов (и сразу их откинуть?):
Вводить опросы по простоте внедрения. Хотя это скорее будут вопросы по общей удовлетворенности проектом внедрения/продуктом и оценка будет зависеть не от пользования продуктом, а от сэкономленных средств, коммуникации между внедренцами и ЛПР,а может и от фазы луны (бывали такие случаи). Да, и метрика эта будет скорее к NPS.
Можно попробовать вводить опросы по базовому функционалу платформы. Например, на этапе выбора ЛПРом. Когда кто-то со стороны клиента ищет некое решение, берет триал на платформу, юзает ее и потом его можно опрашивать. Но на этом этапе также мы не получаем объективных данных так как продукт в базе и адаптированный продукт могут сильно отличаться.
Еще можно было бы вводить опросы для конечных пользователей такого продукта уже после его внедрения в компанию клиента. В таком случае, мы хоть и можем получить объективные данные по уже готовому проекту, но как либо применить эти данные будет проблематично. Так как к другому проекту их применить будет практически нереально (другие процессы, особенности и т.д.), а в рамках текущего проекта можно, но с согласия клиента и оплаты им доработок. Вероятность чего также стремится к нулю.
Метрики по типу CES и CSI, скорее всего, будут отлично работать в b2c или массовом b2b. Где продукт не адаптируется под каждого отдельного клиента.
А жаль. Было бы классно придумать или понять ту точку, в которой можно было бы собрать эти данные по сложному b2b продукту.
Буду рад если кто поделится какими-либо идеями. В качестве продукта можно рассмотреть что-то типа сложных crm систем или систем электронного документооборота.
Неплохие мысли поначалу, но потом в такой догматизм и невежество скатывается, что читать противно. Не удивлюсь, если автор оригинала из тех, кто за серьёзные килобаксы помогает серьёзным дядям "внедрить скрам в сжатые сраки(с)"
Но, вцелом, если брать адекватное и технически подкованное начальство, то оценки нужны не для планирования ресурса, а для приоритизации. Руководителю ведь, как правило, нах не надо выполнить таски 123, 456 и 789 в следующую неделю (за исключением багов на проде или безальтернативных внешних обстоятельств). Ему надо поднять вовлеченность, или уменьшить отток, или заинтересовать новых клиентов и так далее. Ему надо пройти из точки А в точку Б в бизнесе, и, как правило, есть тысячи способов сделать это, а задачи в беклоге это лишь одно из предположений, как. И, поэтому, получив оценки на варианты достижения точки Б от разработчиков, руководитель может оценить, а действительно ли ему надо именно эта таска выполнена, или подойдёт альтернатива, которая приведет бизнес в Б', который не сильно хуже Б, но требует в 3 раза меньше ресурса
Соглашусь с akakoychenko.
У нас это так. Вот мы погружены, вот мы знаем теорию, вот мы экологичны в общении. И что же из этого должно следовать?
А следует то, что мы не можем применить на практике идеально методологию.
Мы можем гибридизировать любую идею, чтобы достичь решения задачи. Далее условности, а не конкретные цифры, просто для простоты подсчета, или сложности. Не знаю. Это бизнес, это рынок, и цель одна, “не нужно себе врать” (с).
У продуктов свои проблемы
Бизнес хочет зарабатывать 5 млн рублей в месяц, ищет варианты, придумывает услуги, продукты (Условно объединил всех в бизнес)
Хочет, чтобы каждый рубль был потрачен эффективно
Еще чтобы это произошло ASAP
Он не хочет текучки и чтобы все были счастливы
Маркетинг хочет, чтобы было красиво, завлекательно
И т.д.
У проектов - свои.
Заказчик хочет заработать денег. Хотя тут чаще на чем-то сэкономить. Отказаться от дорогого и перейти на дешевое.
Купить что-то, чтобы оптимизировать и разогнать бездельников. И т.д.
Везде нужно понять, сколько я, как торговец (назову так), потрачу, чтобы заработать. Вот и юзер стори. С другой стороны, я, как торговец, хочу сэкономить, для этого я заменю неповоротливую систему на современную, модную и т.п.
Сколько мне будет это стоить? Кто мне ответит на этот вопрос? Я выберу. Готов ли я потратить много? А сколько это много? Не врем себе, идем на рынок.
Торговец: кто хочет заработать?
Мы с вами: я хочу, и я хочу.
Торговец: кто может
Мы с вами: я могу, и я могу
Торговец: как же мне сравнить? (я сейчас не буду про тендеры и т.п.). Дайте-ка мне сумму и срок.
Можем мы ответить вилкой? Да, это компромисс.
Но уже и вилка сама по себе получается обман? Здесь можно хоть целую статью писать.
Если смотреть на это как на черное и белое, то возможно автор и прав. Как и любой теоретик прав. И такие взгляды нужны, чтобы был какой-то базис для размышления, внедрения в процессы, проверки гипотез и в итоге гибридизации.
Но на практике мы стараемся получить от этого прибыль в виде прямого дохода или экономии.
И как будто бы вывод один - не возводи в абсолют, думай головой, не верь слепо, а проверяй, применяй, анализируй, меняйся.
Ну почему же сразу все оценки - ложь? Оценка сроков "от нуля до бесконечности" звучит довольно правдоподобно. Я бы еще добавил, что иногда проблема в том, что вместо того чтобы взять решение задачи, которое мы знаем, мы создаем другое решение, потому что это интереснее, и якобы правильнее (я вот регулярно так делаю). )
Эти слова навели меня на вопрос, как не выдумать новое, потому что оно “интереснее”? Никак. Есть маркетинг, внутренний, внешний, есть внешний бизнес-заказчик, есть целые сферы бизнеса, чей поток сознания выливается на ”внедренцев” и ”продуктовиков” каждый день :-). “Интересное” порождает запросы - запросы мы решаем, не все можно собрать из кирпичей, но иногда можно. У нас есть работа - спасибо, интересная - да.
Постоянно получаю ссылки на подобные статьи от руководства, hr, “снизу, сверху, сбоку” и т.п. Надоело быть просто читателем, а тут немного “подгорело”, что называется. Решил зарегистрироваться и написать.
Почему - не знаю, долго думать. Наверное, просто эмоционально перегружен и вспомнил, что такое форумы. А вдруг найду людей, с кем можно конструктивно обсудить понятия и что-то позаимствовать - последнее честно, идеи иногда кончаются ?.
Не буду делить продукты, проекты, продажи и т.п. Не буду говорить, что мы не обманываем себя сроками и т.п. Вообще это философия, истина только одна, и вы все ее знаете :)
Случайно! Поправил, спасибо!
Это прям печальный кейс. Видел когда новый продукт саботируют рядовые сотрудники. Но хуже всего, если этим занимаются топы. Тогда вообще никакого смысла в системе нет.
И как понимаю из вашего комментария, там еще куча проблем с коммуникацией от руководителя. Неумение ставить задачи, строить процессы. Если это собственник, то тут уже вряд ли что поможет :-)
Тоже соглашусь. CRM может отлично бустануть бизнес, но на определенном этапе. Я довольно давно работаю с подобными системами и понимаю, что бывают разные случаи. Некоторые хотят внедрить новую систему просто потому, что “где-то читали и нам тоже нужно”. Или бывает “внедрение для внедрения” просто как элемент освоения бюджета или внутренней политики. Да много разного бывает.
Но, если бизнес понимает, что он хочет решить, при помощи нового продукта, то могут получиться отличные результаты. Так можно структурировать процессы и избавиться от хаоса или ускорить процессы. Правда, у меня больше опыт взаимодействия с крупными заказчиками. И там с этим немного проще.
Главное ставить цели и строить путь к их достижению, если вы хотите внедрить такой продукт.
А на счет того, что нет решения, в котором можно было бы решать все задачи, не могу согласиться. Рекламировать никого не буду, но есть продукты, которые могут закрыть широкий спектр потребностей. С гибкой настройкой, раздачей прав, созданием своих разделов форм, дашбордов и т.д. и т.п. Да, такое решение будет дороже нишевого, но дешевле чем если поднимать его с нуля.
Прежде чем меня закидают помидорами, стоит оговориться, что я пишу скорее про сегмент среднего или крупного бизнеса. Малый тоже может себе позволить подобные решения, но для этого ему понадобится хорошо понимать свои процессы или иметь хорошего аналитика в штате. Цена внедрения для малого бизнеса может оказаться неподъемной.
Плюсую автору. Мы сейчас тестируем NextCloud. Подбираем набор плагинов. Можно сказать, формируем экосистему, под свои нужды.
Но у них очень не удобный маркетплейс. Пробовали и другие аналоги, но пока не получается закрыть потребности комплексно то, чем мы регулярно пользовались в тимс.
Есть и позитивные моменты для нас, как для разработчиков. Открывается много возможностей практического применения чужого опыта. Как редактирование файлов в онлиофис в некстклауд. Можно понаблюдать как это взлетает у коллег по рынку.
Жаль, что пока не все поставщики понимают, что тимс не только про то чтобы чатиться, звонить или рисовать доски. А еще и совместное редактирование документов, версионность файлов. Да и те же созвоны с возможностью записей, выгрузкой в облако и т.д. и т.п. Просто часто вижу рекламу “аналогов тимс”, в которой упор идет на чаты и звонки. Без всех остальных возможностей.
Опять же это будет зависеть от целей заказчика. От того как он понимает проект. Мы со своей стороны приложим все усилия, чтобы сделать проект эффективным. И много клиентов, которые либо “с ходу” приносят свое понимание процессов, понимают цели проекта и действительно хотят создать ценность. Либо во время работы над проектом формируют это понимание. И эти проекты потом радуют. Таких клиентов также много. С ними приятно работать.
Возвращаясь к кейсу, это может быть не то, что мы все представляем под процессом продаж, особенно продаж на потоке. Такая система будет учитывать особенности бизнеса.
Да и про “научить” я нигде не говорил. Про то, что подготовить команду клиента, внедрять продукт постепенно, а не “с двух ног”.
Но я понимаю чем вызван негатив. Сейчас много тех кто говорит или пишет как “истина в последней инстанции”. По типу “мы лучше знаем как должен работать бизнес клиента или заказанный им продукт”. Иногда да, опыт может подсказывать верные решения. Но это всегда совместное творчество. Когда мы хотим сделать так, чтобы клиент получил рост своих метрик эффективности, а мы долгосрочные финансовые отношения с клиентом.
У нас нет шаблонов “как надо”. Мы пилим проект под нужды и требования клиента. И готовы учитывать такие нюансы, как игру в гольф или походы в баню. :)) Спасибо за содержательный комментарий.
В статье я и не думал о глубине темы. Скорее описал свое личное восприятие.
Я с вами согласен, что можно было постараться раскрыть тему прийти к каким-то выводам. Просто хабр, для меня, выполняет скорее терапевтическую функцию. Иногда хочется поделиться своими мыслями и посмотреть на то, как на эти мысли или описанные ситуации реагируют другие участники комьюнити. Многие пишут классные и полезные мысли в комментах. Это здорово!
А так да, прочитал и призадумался. С одной стороны все верно, но если детализировать, то можно заметить ряд моментов, которые также стоит учитывать.
1. Пример с Open AI мне видится немного утрированным. То есть, теоретически можно было бы вообразить, что кому-то потребуется доска, на которой будет процесс генерации каждого промта. Но вероятность того, что такой проект кто-то захочет реализовать, тем более при помощи стороннего подрядчика, стремится к нулю.
Все же от количества процессов, их глубины и сложности также зависит и сам проект. Возможность возникновения потребности в проекте и поиск способов его реализации.
В статье я говорю о процессах, где есть четкие роли, задачи у этих ролей и этапы прохождения этих задач. Не миллионы промтов, а десятки, может сотни действий в день. Более приземленный проект.
Если утрировать, то можно придумать много примеров. Они будут нежизнеспособны, не применимы на практике. Но могут доказывать точку зрения. Мне приятно, что вы постарались изложить свою точку зрения и я бы предложил подискутировать более предметно.
Например, ваш второй кейс. Да, в нем есть ряд отхождений от классического процесса продаж. Но они также могут быть учтены. Мы можем включать или не включать сами эти действия в процесс. Это может быть что-то универсальное, например “Стадия переговоров”. Внутри этой стадии могут быть комментарии: “Клиент любит ходить в баню по субботам и такое-то пиво”. Эти данные мы можем положить в карточку клиента и учитывать в будущем. Ведь сейлз может уйти, а новому сейлзу придется заново выстраивать отношения с этим клиентом.
И это нас приводит к этапам построения процесса. От касания с клиентом и заведения его карточки в базу. И дальше по этапам продажи (индивидуально для данной компании: переговоры, отправлено КП, согласование условий и так вплоть до успеха или провала. Также мы можем ставить задачи в этой системе. Сводить данные по успехам и провалам. Какие менеджеры остаются на “стадии переговоров” и просто ходят в баню с клиентом, но не приносят никаких продаж. И т.д. и т.п.
Здесь речь не идет про то, чтобы всех поставить “к ногтю” и сломать то, что не работает. Сделать эффективнее - да. Понять процессы, найти их уязвимости и точки роста - безусловно.
Что вы имеете ввиду под формализацией, я понимаю. Такое тоже бывает. И зачастую этот процесс происходит на стороне клиента. Изначально цель проекта “формализовать процессы”, а по факту привести их под тот общий знаменатель, каким его видит “биг босс”. А он часто видит процессы как “да что там делать, пять минут и готов”. А это может быть что-то емкое. Вот тогда да, в таких проектах внедрение новой системы может быть неэффективно.
Но если посчитать, что проект не для освоения бюджета, каких-то личных целей менеджеров или других причин, а ориентированный именно на то, чтобы вырастить эффективность работы, то основным критерием успеха проекта будет упрощение работы сотрудников и прозрачное понимание процессов. Возможность оценить те же пресловутые точки роста, моменты провалов и т.п.
По процессам не являющимся ключевой компетенцией (уборка, кофе и т.п.). Ну, мы про них просто не говорим сейчас. Пока не встречал проект, в котором это были бы ключевые этапы процесса. Но если бы такой проект пришел, то можно было бы и его сделать. Почему нет?
Клиент хочет реализовать проект. Он видит в нем ценность. Мы соберем требования, проанализируем процесс, предложим решения. Подготовим документацию, утвердим и реализуем проект.
Надо ли автоматизировать процессы или лучше посадить студента со знанием питона? Да, все индивидуально. Справится студент с питоном, когда в компании много отделов и ролей в них, прав по записям или по операциям, пересекающиеся группы интересов, разные стадии, сегментация клиентов, проектов, есть разные активности, а сверху это все накрывается документооборотом? Маловероятно. А выдержит ли такая система нагрузку, сможет ли она масштабироваться? Тоже вряд ли.
Зааутсорсить тоже можно. Только, что вы вкладываете в это понятие? Мы вот, как внедренцы, тоже аутсорсом занимаемся. Или речь о том, чтобы зааутсорсить этапы работы, передавать рабочие документы, контакты клиентов? Мало кто бы на это согласился. Если отдать на аутсорс уборку и кофе, то да, вопросов не имею.
Должен ли бизнес знать процессы? Вопрос интересный. Зависит от уровней. Если мы говорим, должен ли гендир большого холдинга знать как конкретные сейлзы по скрипту работают? Нет конечно. Это был бы снова утрированный пример. А вот должен ли РОП знать как строятся продажи в его отделе – безусловно. Так и строится структура проекта. Кто-то ответственный от компании собирает требования от стейкхолдеров (РОПы, РОМы, РП, PR, менеджеры и т.д.). Каждый на своем месте. Каждый ответственен за свой “кусочек пирога”. Потом этот человек все сводит воедино и передает нам. Мы на всех этапах стараемся ему помочь.
Были ли идеальные проекты, когда получилось сразу реализовать проект, который закрывал бы 100% потребностей? Возможно. Но я не встречал такие. Круто, если получается закрыть 60-70%, потом будут доработки и оптимизация. Уточнение требований. Особенно когда РОП посмотрит на готовый проект и поймет что ему еще чего-то не хватает, оно жизненно необходимо, а он просто об этом забыл, при составлении требований. Такое постоянно происходит.
Должен ли знать сотрудник процессы своей компании? Нет, не должен. Но должен быть наделен полномочиями, которые позволят эти процессы “снять”, систематизировать и сделать ту работу, которая от него требуется.
Да и моя статья не столько про незнание процессов, сколько про обычную лень. Когда клиент не хочет собирать процессы, когда тех дизайн подписывается “не глядя”, а перед сдачей проекта выясняется, что “это не то, что нам надо”. Да и про много чего еще. Просто это проще объединить про “незнание процессов”. Потому что и внутри своих отделов, подразделений клиенты часто не знают что происходит.
Еще раз спасибо за комментарий! Я только начинаю писать. И тема, для меня, по своему, эмоциональная. Так что “интересная тема поднята, но глубина и близко не раскрыта, увы…” – меня немного взгрустнуло. Но ваш комментарий заставил меня поразмышлять. Вот, делюсь с вами, своими размышлениями.
Но тогда вопрос. Как “врываться к исполнителям”, если это проект клиента и он сам дает выделенного менеджера?
То есть для нас заказчик выглядит как определенный менеджер или некий комитет, через который решаются все вопросы. У нас есть регламенты и документация, которые позволяют лучше вникнуть в процессы клиента и проработать все проекты “на берегу”. Аналитики, как могут, вытягивают из клиента данные по процессам. Но этот набор регламентов и документов, которые согласуются с клиентом, иногда не гарантирует точного понимания процессов клиента.
В какой-то момент вообще, может оказаться, что проект, который создавался на протяжении полугода, совсем нерелевантен целям клиента. Мы совместно с клиентом начинаем копать и оказывается, что на этапе согласования представитель заказчика просто не прочитал технический дизайн, подписал его просто потому что “да что там делать?” А это проект с массой зависимостей, ролей и т.д. и т.п.
Или такой проект сваливается просто под действием внутренней политики компании клиента. Когда человек, который отвечает за внедрение, внутри компании клиента, не хочет, чтобы проект был сделан. Ему, по каким-то своим причинам, выгодно чтобы проект не был успешен. И это не будет озвучено вслух. Просто постепенно, в процессе работы, начнут происходить “странности” и чем дальше тем все “страньше и страньше”. Но это отдельная тема, по которой можно много чего рассказать. И сейчас не вижу смысла углубляться.
Еще есть nda (иногда доходит до полнейшего маразма, когда представитель клиента не может дать жизненно важную, для проекта, информацию), такие же проблемы с ИБ, саботаж на уровне пользователей проекта (рядовых сотрудников), проект, который изначально был для “освоения бюджета” и в компании никто, на самом деле, не заинтересован в его завершении, а еще интриги, скандалы, расследования. Да еще много чего бывает. Какие-то моменты реже, какие-то чаще.
Но бывает и обратная сторона. Есть клиенты, представители которых, действительно заинтересованы в успешном завершении проекта. И представители такой компании почему-то знают и процессы, и роли да и то, что не знают, быстро узнают и вносят в документацию.
Да, при этом невозможно сразу охватить все. Поэтому есть поддержка, обучение клиента и возможность “докручивания” проекта нашими силами.
Бывают такие клиенты. И их тоже не мало. Просто здесь пишу о том, что занимает больше сил и энергии. А значит и рефлексии, ей и делюсь.
Тут речь скорее не про “красивые сказки”, а про то какие внутренние цели стоят перед самой компанией и ее представителями. Какая у этих представителей компетенция, погруженность в рабочие процессы. Нужно ли такому “внутреннему внедренцу” создать видимость деятельности, заинтересован ли он в новом проекте или он получает какие-то преференции со старого решения и ему выгодно оставить “как есть”, даже если это тормозит всю компанию.
Ну и статья скорее про мой личный нытинг.
Спасибо за комментарий. Согласен с вами.
По менеджменту, да. Тут проблема не только в том, что учат “управлять чем угодно”, а еще и в том, что многие “эффективные менеджеры” не стремятся понимать суть процессов, механизмов своих компаний, отделов и т.п. А вместо этого, устраивают политические игры или просто пытаются “выжать” все что можно. И делается это все не для создания ценности, в том числе своей, как профессионала, а для построения имитаций.
С культурой – в самое яблочко!
Правда не всегда и не все так плохо. Есть классные менеджеры, которые понимают и свои процессы и стараются генерить ценность. С ними приятно работать. Просто те о ком мы тут с вами пишем, требуют больше трудозатрат и сил. Поэтому их кажется больше.
Согласен, но частично. Согласен с тем, что есть такие проблемы, но не согласен с какой-то обреченностью, которую, как мне кажется, уловил в вашем комментарии. Если это не так, то извините, значит показалось. Но тем не менее попробую описать то, с чего можно было бы начать решать эти проблемы. Пойду снизу вверх:
1. Про “дикое сопротивление, вплоть до увольнения”. Саботаж при введении новых систем и процессов, со стороны рядовых сотрудников, это распространенная проблема. Но благодаря этому также есть много возможностей, как повлиять на своих сотрудников.
Первое с чего стоило бы начать – узнать с чем вообще связано недовольство. Главное выделить те проблемы, которые чаще всего встречаются. Это могут быть как объективные проблемы (как “новая система/процесс увеличивают время решения задач или делают их менее удобными, чем было раньше”) или субъективные проблемы (утрировано “не нравится цвет кнопок” или просто “пофиг, что новая система автоматизирует рутинные задачи, мне в экселе было удобнее”). В идеальном мире, это можно было провести на начальных этапах работы с проектом. Но мы живем в нашем мире и хорошо бы такое исследование проводить хотя бы в процессе работы, когда доработки займут минимум времени и рисков.
С объективными проблемами, думаю, что все понятно. Собираем данные, анализируем и вносим их в роадмап проекта. Тестируем и смотрим на реакцию сотрудников.
А вот с субъективными проблемами будет сложнее. Нужно копать не в сами отзывы, а скорее в то, с чем вообще связан негатив. В то на сколько выстроены процессы (да, вы писали, что их нет и об этом также напишу ниже), как выстроена культура в команде, на квалификацию сотрудников (может они действительно могут только гугл таблицу открыть и там вручную что-то повносить). Также стоит посмотреть на то, какие есть группы сотрудников и интересы у этих групп. Я видел как хорошие проекты “падали” просто за счет того что внутри компании заказчика есть разные “политические силы”. И кому-то было просто выгодно, чтобы ничего не менялось.
Также посмотрите на то, как вы донесли до сотрудников важность новых систем и процессов. Провели ли обучение и на сколько качественным оно было. На сколько сотрудники поняли как это должно работать и как это повлияет на их работу. Улучшит ли новое их рабочий опыт?
2. “Нет бизнес процесса”. Не хочу показаться грубым, но начните выстраивать процессы. Пропишите регламенты, что, как, куда и зачем. Изучите методологии работы, которые есть. Посмотрите что вам лучше подойдет и облегчит работу сотрудников, сделает ее понятной и логичной. Только не гонитесь за модными agile и т.п. Выбирайте то что подойдет под ваш бизнес. Поймите самую суть ваших процессов, того как они должны работать, какой путь должен проходить лид или отдельная задача. Где образуются “узкие места”. Выстраивайте процессы по чуть-чуть и начните с самых важных.
Основных задач, при выстраивании процессов, я вижу две: упростить/ускорить процессы для сотрудников и сделать их прозрачными для менеджмента.
Первое позволит снять лишнее напряжение с сотрудников. Сделать так, чтобы они не тратили кучу энергии и времени на постоянное переключение между задачами/вкладками/типом действий (переключение между чем-то тоже можно рассматривать как часть процесса) и на то, чтобы постоянно разбираться в том, чего они не знают или не понимают. Чем понятнее и точнее описаны задачи, тем проще их решать и тем выше вероятность их эффективного решения.
3. По отсутствию связей и перегруженности. Это также к процессам. Если вы не понимаете как должна двигаться задача и где они агрегируются. На каком-то человеке/отделе, то вы не сможете с этим разобраться.
4. “Утеря компетенции и переход к ритуалам”. Поговорите со своими сотрудниками. Поймите с чем это связано. Почти наверняка выйдите на нерабочие или неэффективные процессы. Когда человек, который умеет круто продвигать задачи вынужден “перекладывать данные из одной эксельки в другую” или когда “эффективный менеджер оказывается просто самодуром, которому лень искать точки роста и он просто ставит задачи ради задач”. Вариантов может быть масса.
Также, если поговорить с сотрудниками, то может оказаться, что кто-то из них знает как решить проблему. Хотя бы локально, на своем месте или в отделе. Соберите и проанализируйте такие предложения, посмотрите что “бьется” с вашим видением процессов, с тем как оно работало бы эффективнее и начните внедрять это.
Также важно помнить, что процессы это не про то чтобы было удобно именно вам или не про то чтобы копировать то как “у дяди Пети”, а про то чтобы именно ваш бизнес начал работать с высоким кпд.
5. “Размывание ответственности”. У вас же каждая задача имеет исполнителя и проверяющего? Ведь так? Если да, то вы должны понимать кто и за что отвечает.
А ваши сотрудники, почему они “размазывают ответственность”? С чем это связано? Если случился провал по задаче, вы как-то его прорабатываете? Если да, то как? Завязаны ли провалы на деньги или какие-то еще формы “кнута”?
Самое главное здесь понять почему это происходит. Вопрос в сотрудниках, в организации процессов или в руководителе? В любом случае, это будут полезные данные.
SQLite - первый релиз в 2000г, последняя версия 2024г
ТеХ первый релиз в 1978г, последняя 2021г
К сожалению не знаю всю историю версий, но сомневаюсь, что за столько времени разрабатывались только фичи без багфиксов и оптимизации, а также что за столько времени все возможные баги были отловлены и пофикшены до попадания в очередной релиз. В целом, подобный срок достаточный для обширного сбора обратной связи и её обработки.
История с open source приложениями это история энтузиастов. В статье я писал о том, что есть люди, готовые потратить своё личное время на повышение качества разрабатываемого в рамках своей работы ПО, такие люди редкость и примерно такие же и занимаются разработкой подобных продуктов.
Также в open source специалист, как правило, не так ограничен в сроках, ведь над ним не стоит руководство, тыкающее его лицом в дату очередного релиза с набором требований, которые к этой дате в этом ПО должны быть.
Описаны полезные и применимые принципы.
Не очень люблю слово agile, которое сейчас "пихают" везде и всюду, скорее как некую религию. Но то, что описано в статье, это все можно применять, а мы даже и применяем.
В результате, мы получаем высокий уровень компетенций, ответственности, самоуправления и эффективности на производстве. К минусам можно отнести то, что нужно быть готовыми к росту фот, а также к его скачкам, чаще вверх, чем вниз. Я бы назвал статью как-то типа принципы менеджмента, диктуемые рынком.
Да, все так. Зачем делается продукт стратегически, какие от него ожидания у бизнеса/стейкхолдера и сколько готовы в него вложить.
Тут стоит учитывать вопрос денег. Даже если это разработка внутреннего продукта, то она также оплачивается из бюджета компании. И такой продукт также будет иметь свои требования со стороны бизнеса.
А если бизнес, в своих требованиях, не учитывает или считает доработку качества ПО лишним, то с точки зрения описанного в статье, внутренний продукт не будет отличаться от клиентского.
Все упирается в цели бизнеса и в количество времени/средств, которые он готов вложить в разработку.
Коллега, приятно увидеть, что не только мы пришли к таким практическим гибридам.
За 10 лет мы пробовали внедрять, кажется, все, что только можно.
В итоге через "кровь и пот" пришли к гибридам. Прописали свои манифесты и правила (Как правила дорожного движения - "написанные кровью").
Продолжаю читать статьи и раз за разом вижу теории.
И "о чудо!" первый раз вижу команду, которая пришла к абсолютно такой же схеме работы.
Разве что оценки у вас в "мерках", а у нас в числах Фибоначчи.
Буду следить за вашим опытом теперь.
Удачи вам и нам - меньше страданий, больше эффекта.
Спасибо за статью.
На самом деле классная метрика. Единственное, что непонятно как ее трекать в “глубоком b2b”. Например для проектного внедрения. Когда продукт представляет собой платформу, которая адаптируется под требования каждого клиента.
И когда например, конечный юзер и тот кто покупает продукт, - разные люди.
То есть внедрение продукта аппрувит бизнес (ЛПР), а пользуются продуктом сотрудники компании.
Хотя, если так подумать, то с ходу можно попробовать несколько вариантов (и сразу их откинуть?):
Вводить опросы по простоте внедрения. Хотя это скорее будут вопросы по общей удовлетворенности проектом внедрения/продуктом и оценка будет зависеть не от пользования продуктом, а от сэкономленных средств, коммуникации между внедренцами и ЛПР,а может и от фазы луны (бывали такие случаи). Да, и метрика эта будет скорее к NPS.
Можно попробовать вводить опросы по базовому функционалу платформы. Например, на этапе выбора ЛПРом. Когда кто-то со стороны клиента ищет некое решение, берет триал на платформу, юзает ее и потом его можно опрашивать. Но на этом этапе также мы не получаем объективных данных так как продукт в базе и адаптированный продукт могут сильно отличаться.
Еще можно было бы вводить опросы для конечных пользователей такого продукта уже после его внедрения в компанию клиента. В таком случае, мы хоть и можем получить объективные данные по уже готовому проекту, но как либо применить эти данные будет проблематично. Так как к другому проекту их применить будет практически нереально (другие процессы, особенности и т.д.), а в рамках текущего проекта можно, но с согласия клиента и оплаты им доработок. Вероятность чего также стремится к нулю.
Метрики по типу CES и CSI, скорее всего, будут отлично работать в b2c или массовом b2b. Где продукт не адаптируется под каждого отдельного клиента.
А жаль. Было бы классно придумать или понять ту точку, в которой можно было бы собрать эти данные по сложному b2b продукту.
Буду рад если кто поделится какими-либо идеями. В качестве продукта можно рассмотреть что-то типа сложных crm систем или систем электронного документооборота.
Соглашусь с akakoychenko.
У нас это так. Вот мы погружены, вот мы знаем теорию, вот мы экологичны в общении. И что же из этого должно следовать?
А следует то, что мы не можем применить на практике идеально методологию.
Мы можем гибридизировать любую идею, чтобы достичь решения задачи. Далее условности, а не конкретные цифры, просто для простоты подсчета, или сложности. Не знаю. Это бизнес, это рынок, и цель одна, “не нужно себе врать” (с).
У продуктов свои проблемы
Бизнес хочет зарабатывать 5 млн рублей в месяц, ищет варианты, придумывает услуги, продукты (Условно объединил всех в бизнес)
Хочет, чтобы каждый рубль был потрачен эффективно
Еще чтобы это произошло ASAP
Он не хочет текучки и чтобы все были счастливы
Маркетинг хочет, чтобы было красиво, завлекательно
И т.д.
У проектов - свои.
Заказчик хочет заработать денег. Хотя тут чаще на чем-то сэкономить. Отказаться от дорогого и перейти на дешевое.
Купить что-то, чтобы оптимизировать и разогнать бездельников.
И т.д.
Везде нужно понять, сколько я, как торговец (назову так), потрачу, чтобы заработать. Вот и юзер стори. С другой стороны, я, как торговец, хочу сэкономить, для этого я заменю неповоротливую систему на современную, модную и т.п.
Сколько мне будет это стоить? Кто мне ответит на этот вопрос? Я выберу. Готов ли я потратить много? А сколько это много? Не врем себе, идем на рынок.
Торговец: кто хочет заработать?
Мы с вами: я хочу, и я хочу.
Торговец: кто может
Мы с вами: я могу, и я могу
Торговец: как же мне сравнить? (я сейчас не буду про тендеры и т.п.). Дайте-ка мне сумму и срок.
Можем мы ответить вилкой? Да, это компромисс.
Но уже и вилка сама по себе получается обман? Здесь можно хоть целую статью писать.
Если смотреть на это как на черное и белое, то возможно автор и прав. Как и любой теоретик прав. И такие взгляды нужны, чтобы был какой-то базис для размышления, внедрения в процессы, проверки гипотез и в итоге гибридизации.
Но на практике мы стараемся получить от этого прибыль в виде прямого дохода или экономии.
И как будто бы вывод один - не возводи в абсолют, думай головой, не верь слепо, а проверяй, применяй, анализируй, меняйся.
Спасибо за возможность выразить мысль.
Выше писали
Эти слова навели меня на вопрос, как не выдумать новое, потому что оно “интереснее”? Никак.
Есть маркетинг, внутренний, внешний, есть внешний бизнес-заказчик, есть целые сферы бизнеса, чей поток сознания выливается на ”внедренцев” и ”продуктовиков” каждый день :-).
“Интересное” порождает запросы - запросы мы решаем, не все можно собрать из кирпичей, но иногда можно. У нас есть работа - спасибо, интересная - да.
Привет всем.
Постоянно получаю ссылки на подобные статьи от руководства, hr, “снизу, сверху, сбоку” и т.п. Надоело быть просто читателем, а тут немного “подгорело”, что называется. Решил зарегистрироваться и написать.
Почему - не знаю, долго думать. Наверное, просто эмоционально перегружен и вспомнил, что такое форумы. А вдруг найду людей, с кем можно конструктивно обсудить понятия и что-то позаимствовать - последнее честно, идеи иногда кончаются ?.
Не буду делить продукты, проекты, продажи и т.п. Не буду говорить, что мы не обманываем себя сроками и т.п. Вообще это философия, истина только одна, и вы все ее знаете :)
Как оно бывает на практике, вы тоже знаете.