В семнадцатом выпуске подкаста Радио “Аналитик“ обсудили, как представители сфер foodtech и e-com определяют, что пора автоматизировать процессы, на что обращают внимание при выборе подрядчика, что ценят в коммуникациях и как определяют, успешно выполнена автоматизация или нет.
Гость эфира:Павел Вепрев, директор бизнес-продуктов Chibbis.ru, сервиса по доставке еды, который представлен более чем в 180 городах РФ.
Ведущая подкаста: Мария Серёгина
О чем поговорим:
1:38 - про компанию Chibbis.ru
5:01 - про опыт Павла в автоматизации и оптимизации процессов
10:40 - как определяют, что пора автоматизировать процесс
14:30 - на что обращают внимание при выборе подрядчика
39:22 - про общение на языке бизнеса и на языке разработчиков
46:21 - про затраты на автоматизацию и ожидаемые результаты
53:22 - про коммуникации заказчиков с подрядчиками
На промежуточном демо бизнес уже видит работающие формы и сценарии, хотя внутри решения еще остаются заглушки, ограничения и незаконченная логика, поэтому очень легко создать впечатление, что до запуска осталось совсем немного. Разбираю, как показывать незавершенное решение так, чтобы получить полезную обратную связь, но не превратить каждый комментарий в обещание новой функции или срока.
Хочется рассказать о проекте, достаточно масштабном для нашей компании, который мы успешно выполнили в этом году. Думаю, что материал может быть полезен для ознакомления с примером реализации внедренческой задачи с использованием проектного подхода. Краткое содержание: сначала описана исходная ситуация у заказчика, далее приведены этапы проекта и табличка с подробным описанием содержания этапов. В конце подведены итоги: что получил заказчик и какие у него дальнейшие планы.
Похожую доработку уже выполняли за 40 часов, поэтому заказчик ожидал такой же оценки во второй раз. Но первый специалист давно знал проект, а второму пришлось начинать с изучения чужого кода и накопленных изменений. Разберём, что на самом деле находится внутри прошлого срока.
Как управлять ожиданиями заказчика на 1С-проекте: фиксировать границы задачи, проговаривать ограничения, показывать риски, объяснять этапы, согласовывать критерии приемки и не обещать то, что потом превратится в аврал, конфликт или бесконечные доработки.
Команда может активно работать, но для клиента по ощущением она тормозит, если он не видит статусов, следующего шага и понятного движения. Разбираю, как не доводить проект до ситуации, когда объяснения уже звучат как оправдания.
Когда задачу еще уточняют, а срок уже требуют назвать, дата легко превращается в обещание на удачу. В статье разбираю, как говорить с заказчиком о сроках при плавающих вводных: что фиксировать, как объяснять переоценку без конфликта и почему старый срок не обязан выдерживать новую версию задачи.
Компромиссы в проектах автоматизации часто не решают конфликт, а лишь откладывают проблему и оставляют под угрозой потребности обеих сторон. На трех типичных ситуациях – споре с заказчиком об оценке, конфликте с разработчиком вокруг требований и сопротивлении пользователя новой версии – показываем, где участники на самом деле спорят не о действиях, а о неопределенности. Объясняем, как в теории ограничений работает инструмент «туча» и почему любая проблема в ТОС рассматривается как конфликт. Показываем, почему в возможность win-win-решения выгоднее верить и как такой подход помогает искать не компромисс, а более устойчивое решение.