Процессы важнее целей Этот принцип я перенял из моего софтваре инжинирского бэкграунда. Цель бывает действительно важнее, например, когда необходимо создать в сжатые сроки и с минимальным бюджетом показать жизнеспособность идеи и создать MVP. Создаем продукт, получаем финансирование, нанимаем еще разработчиков и сталкиваемся дилеммой, куда важнее направить усилия: создание новых фич или отладка процессов. Сразу полностью «делать хорошо» обычно не удается, поэтому начинающие компании пытаются подобрать оптимальное соотношение. Чтобы и новые невероятные возможности показывать заказчикам, и укреплять процессы разработки. Иначе можно столкнуться лбом со стеной задач из технического долга, без решений которых дальнейшее развитие невозможно. Как оказалось, опыт прекрасно транслируется и в политические организации (а возможно и в любой другой сценарий кооперации). Как правило, в отсутствии построенных процессов разработки и деления знаниями возникают «тащители». Это специалисты с самым большим и глубоким знанием продукта. Им некогда делиться информацией с другими, писать документацию, тесты, ходить на ретро и другие встречи. Им нужно тащить. Тащат с полной самоотдачей и усердием. Руководство им рукоплещет, говорят так держать, ставят в пример другим. И так до полного выгорания, когда от проекта их начинает неконтролируемо рвать. А когда такой ценный специалист выходит из строя, весь проект сталкивается с полным ступором. Процессов не было, знания никто никуда так и не передал. Остается восстанавливать по крупицам тайны из чертог разума такого тащителя. Сталкиваться с кошмарами за пределами человеческого понимания, так сказать. Так и что делать? Строить процессы. Будет тяжко и сложно. Если организация на волонтерских началах, то кошмары могут быть невыносимыми. Но итогом может стать как раз тот самый механизм, где не один человек делает все за всех, а каждый делает то, что в его компетенции. Добиваться результата будет крайне сложно, первые итоги могут быть и вовсе далеки от приемлемости. Главное не поддаться голосам в голове, что будут убеждать все делать самому и в одиночестве. Со временем механизм станет работать быстрее и проще. Его части могут легко подменять друг друга, передавать знания дальше, создавать новые механизмы для еще более амбициозных целей. И именно тогда продукт действительно сможет показать свою жизнеспособность. ПАНАРХИЯ СЕЙЧАС