Тендеры и лиды
Информация
Представьте, что вы запустили новый процесс в уже устоявшуюся схему разработки и ждёте прироста эффективности. Вместо этого все начинает затягиваться, люди не успевают выполнить свою работу в нужный срок, процесс буксует. Казалось бы, это идет обкатка и принятие нового, но новые процессы редко ломают всё в один момент. Они убивают мораль по капле - в мелочах, которые менеджмент не замечает, пока система не даёт сбой.
Мы собрали ТОП список из вещей, в которых чаще всего буксуют процессы и реальные примеры из практики.
Вместо оперативного решения вопроса, нужно собрать одобрение у нескольких ЛПРов, которые не могут договориться между собой. Срочная задача превращается в цепочку согласований, при этом сама ответственность смазана. Один сотрудник дает одобрение, другой приходит с новыми идеями и так по кругу.
Пример: изменение карточки товара требует согласование маркетинга, продакта и юр отдела, в результате ряд блоков, работа которых не очевидна, продолжают существовать на сайте в старом представлении.
Как можно действовать: назначить ключевое лицо, принимающее решение, за которым будет финальное согласование.
При реализации той или иной функциональности нужно согласовать требования. Попытки найти сотрудников, ответственных за отдельные составляющие системы не приводят к успеху. Процесс сбора требований затягивается. Аналитик ходит по кругу, пытаясь собрать информацию. Люди перекладывают ответственность друг на друга. Как итог - теряется всякая инициатива.
Пример: необходимо реализовать механику, в рамках которой при сканировании QR-кода в оффлайн точке пользователь переходит в определенный раздел интернет-магазина. Для корректного сбора аналитики необходимо проставить метки, идентифицирующую точку расположения кода. Однако, нет четкой определенности, кто будет генерировать ссылки для QR и какие данные нужно собирать, чтобы получить нужную статистику.
Как можно действовать: на первом шаге нужно по возможности собрать по одному ответственному сотруднику от каждого из отделов, получить базовую вводную информацию от каждого из них, после собрать всех на несколько сессий созвонов и прийти к общему соглашению.
Новые чек‑листы, дополнительные шаги проверки, отчеты на каждый шаг. Все это подается под соусом улучшения качества, однако, чувство недоверия демотивирует и замедляет все процессы.
Пример: даже самые простые задачи после тестирования проходят повторную итерацию проверки от нескольких отделов. По итогам каждой итерации выдвигаются новые улучшения. Процесс приемки удлиняется. Стоимость разработки возрастает.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13201 тендер
проведено за восемь лет работы нашего сайта.
Как можно действовать: сократить количество звеньев в цепочке проверки до оптимального, оставив только 1й этап верификации качества и 2й этап проверки соответствия бизнес-требованиям с последующим демо для бизнеса. Все предложения по улучшению выносить в дополнительные задачи и добавлять их в бэклог.
В компании внедряется новый инструмент или процесс, но не проводится предварительное обучение. Люди начинают совершать ошибки, стесняются задавать вопросы.
Пример: компания выпускает новую релизную политику. Определены, но не задокументированы этапы проведения релиза и сценарии возможного поведения. Сотрудники теряются в зонах ответственности и путаются в процессе.
Как можно действовать: быстрый 60‑минутный созвон и запись инструкции с дальнейшим размещением на wiki/в Confluence.
Проект живёт по новым правилам каждый понедельник. У людей нет опоры, ощущение бессмысленности растёт.
Пример: еженедельно меняется приоритезация задач. Сначала определен один список задач, но в середине спринта он может резко измениться.
Как можно действовать: доводить до конца уже начатые задачи, поскольку при таких условиях велика вероятность, что усилия разработки туда не вернутся. Любое изменение в приоритетах должно вести за собой запись причины, цели и влияния на сроки.
В заключение стоить отметить, что любые изменения должны опираться на конкретные слабые стороны процесса. Улучшения ради улучшений - бессмысленны. Любое изменение всегда предполагает переходный период и адаптацию всех задействованных в процессе лиц и на первых этапах улучшения будут едва ли заметны. Стоит помнить и том, что если процесс уже поставлен на рельсы и едет, лучше не трогать его без объективных на то причин, т. к. изменения могут привести и к негативным последствиям, от которых пострадает как команда, так и результат.
