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