Запуск — это начало обычной работы, а не конец проекта
В первые недели после запуска сотрудники начинают пользоваться программой каждый день и сразу замечают то, чего не было видно на приёмке. Кто-то не находит нужную кнопку, у кого-то не сохраняется документ, кто-то просит добавить поле, без которого ему неудобно. Эти сообщения приходят в личные мессенджеры, звучат в коридоре, пересылаются руководителю — и через месяц уже никто не помнит, что из этого исправлено.
При заказной разработке ПО работа с исполнителем не заканчивается в день запуска: программу нужно поддерживать и развивать. Чтобы это не превращалось в поток срочных просьб и споров о том, кто за что платит, стоит заранее договориться о четырёх вещах. Куда сотрудники пишут о проблемах. Кто внутри компании отвечает за программу. Как разбирают ошибку. Как заказывают изменение. Ниже — что входит в каждую договорённость и как проверить, что она действительно есть.
Одно место для всех обращений
Первое правило простое: у обращений должен быть один адрес. Это может быть общая почта, отдельный чат, таблица или раздел в самой программе — форма менее важна, чем то, что все сотрудники знают про это место, а сообщения в нём не теряются и видны ответственному. Просьбы, отправленные лично разработчику в обход этого канала, потом труднее всего найти и обсудить.
Попросите сотрудников писать так, чтобы обращение можно было разобрать без перезвона: что человек делал, что ожидал увидеть, что получилось вместо этого, когда это случилось и в каком месте программы. Снимок экрана помогает понять, о чём речь, без долгой переписки. Не нужно требовать технических формулировок — достаточно описать свой шаг работы обычными словами.
Ответственный за программу внутри компании
Исполнитель не знает ваших приоритетов и не должен их угадывать. Поэтому со стороны компании нужен человек, который отвечает за программу: читает обращения, отвечает на простые вопросы сам, отделяет ошибки от пожеланий и решает, что передавать исполнителю и в каком порядке. Это не обязательно руководитель и не обязательно специалист по технике. Важнее, чтобы он хорошо понимал работу, которую поддерживает программа, и имел право принимать решения.
Договоритесь, что заказывать изменения у исполнителя может только этот человек (и его заместитель на время отпуска). Тогда у исполнителя один собеседник, а у компании — один список того, что уже заказано. Сотрудники при этом никого не теряют: они по-прежнему пишут в общий канал и получают ответ.
Вопрос, ошибка или новое пожелание
Обращения удобно делить на четыре вида: с каждым поступают по-разному. Полезно договориться об этом заранее — и внутри компании, и с исполнителем. В таблице «где фиксируется итог» означает место, куда записывают решение по обращению, чтобы через месяц можно было найти, что именно сделали и почему.
| Обращение | Кто принимает и кто решает | Где фиксируется итог |
|---|---|---|
| Вопрос «как это сделать»: программа работает, человек не знает как | Принимает и обычно сам отвечает ответственный в компании; исполнителя подключают, если ответа нет | Ответ в канале обращений; повторяющиеся вопросы — в короткую памятку для сотрудников |
| Ошибка: программа работает не так, как договаривались при заказе и приёмке | Принимает ответственный, проверяет и передаёт исполнителю; исправляет исполнитель | В списке обращений: что сломалось, что исправлено, кто проверил |
| Новое пожелание: нужно, чтобы программа делала то, о чём не договаривались | Принимает ответственный и решает, нужно ли это; объём и стоимость оценивает исполнитель | В списке изменений: зачем нужно, решение, оценка, срок |
| Сбой: программа недоступна или данные пропали | Сообщают сразу ответственному и исполнителю по заранее оговорённому способу; восстанавливает тот, кто отвечает за работу программы | Отдельная запись: что случилось, что потеряно, что сделано, чтобы не повторилось |
Труднее всего провести границу между ошибкой и пожеланием. Сотруднику всё равно, как это называется: ему неудобно. Но для договорённости с исполнителем разница важна, потому что исправление ошибки и новая работа могут оплачиваться по-разному. Опорой служит то, что было записано при заказе и проверено на приёмке, но сверять обращение нужно с согласованной возможностью и её границами, а не с перечнем примеров.
Если согласованная функция не срабатывает на данных, которые в эти границы укладываются, — это ошибка, даже когда именно такой случай в описании отдельно не назван: договорились сохранять документы с русскими названиями — значит, документ с буквой «ё» в названии тоже должен сохраняться. Изменение — это просьба, чтобы программа делала больше, чем договаривались: новая возможность, новый вид данных или выход за согласованные границы. Если по описанию нельзя понять, где проходит граница, не ставьте ярлык в одиночку: запишите расхождение — что ожидали, что получилось и что сказано в описании — и договоритесь с исполнителем, как считать это обращение. Как будет оплачена работа, решает ваша договорённость об оплате, а не одно название обращения.
Как разбирать ошибку
Порядок разбора лучше один раз проговорить и записать. Ответственный получает обращение и пробует повторить проблему сам — часть «ошибок» на этом шаге оказывается вопросом или неверно введёнными данными. Если проблема повторяется, он сверяет её с описанием, по которому принимали программу, и решает, ошибка это или пожелание. Ошибку передают исполнителю с шагами, при которых она проявляется, и с тем, что должно было получиться.
Когда исполнитель сообщает об исправлении, ответственный проверяет его на том же случае, а не просто ставит отметку. Только после этого обращение закрывают и сообщают сотруднику, который о нём написал. Если исправление не сработало, обращение возвращается исполнителю с тем же номером или в той же записи, чтобы история не терялась.
Отдельно договоритесь, что считается срочным. Остановка работы целого отдела и неудобный порядок полей — разные ситуации, и ждать от исполнителя одинаковой скорости по обеим бессмысленно. Сроки реакции бывают только такими, какие записаны в договорённости; без неё их нет.
Как заказывать изменения, чтобы каждое не стало новым проектом
После запуска пожеланий может оказаться больше, чем возможностей их выполнить. Если передавать исполнителю каждое по мере поступления, программа превращается в набор срочных доработок, а бюджет расходуется на то, что попросили громче. Удобнее вести один список изменений и время от времени пересматривать его целиком.
При пересмотре ответственный задаёт по каждому пункту несколько вопросов. Сколько людей это затрагивает и как часто? Что происходит сейчас без этого изменения — люди тратят лишнее время, делают ошибки или просто испытывают неудобство? Нет ли решения без доработки, например другого порядка работы? После этого исполнитель оценивает выбранные пункты, и вы решаете, что делать сейчас, что позже, а что не делать вовсе.
Небольшие изменения удобно собирать в пакеты и проверять вместе. Крупное изменение, которое затрагивает несколько отделов или меняет порядок работы, лучше оформлять как отдельный небольшой заказ: с описанием, оценкой и проверкой результата — так же, как при первом запуске.
Что обсудить с исполнителем и записать
Договор на разработку программного обеспечения на заказ может описывать только создание и сдачу программы. Тогда сопровождение остаётся устной договорённостью, а устные договорённости хуже всего переживают первый спор. Проверьте, что после запуска на бумаге есть ответы на следующие вопросы.
Как исполнитель получает обращения и от кого. Как вы вместе отличаете ошибку от изменения и кто решает спорный случай. Как оплачиваются исправления и изменения: здесь возможны разные варианты, например срок, в течение которого исправления входят в уже оплаченную работу, оплата по затраченному времени или постоянная ежемесячная договорённость. Ни один из них не действует по умолчанию — важно выбрать и записать свой. В какое время исполнитель отвечает и что он делает при срочном сбое. Кто отвечает за то, чтобы программа работала и восстанавливалась после сбоя, и где хранятся копии данных.
И последнее: что будет, если исполнитель перестанет отвечать или вы решите работать с другим. Доступы, описание программы и история обращений должны оставаться у компании, иначе продолжить работу будет трудно.
Проверьте себя
После запуска у компании есть
- Одно место, куда сотрудники пишут обо всех проблемах и пожеланиях, и все об этом знают.
- Ответственный за программу внутри компании и его заместитель на время отсутствия.
- Правило, что изменения у исполнителя заказывает только ответственный.
- Описание, по которому принимали программу, — опора для решения «ошибка или изменение».
- Записанный порядок разбора ошибки: повторить, сверить, передать, проверить, сообщить.
- Понимание, что считается срочным сбоем и кому о нём сообщать в первую очередь.
- Один список изменений и договорённость, как часто его пересматривать.
- Письменная договорённость с исполнителем об обращениях, оплате исправлений и изменений, времени ответа.
- Доступы, описание программы и история обращений, которые остаются у компании.
Если каких-то пунктов не хватает, начните с первых двух: общий канал и ответственный. Остальные договорённости проще выработать, когда обращения уже собираются в одном месте и их кто-то читает. Следующий практический шаг — назначить ответственного и вместе с ним за неделю собрать все обращения, которые сейчас разбросаны по перепискам.