Ясность, компьютеры и стартапы
«Ясность» - это управленческий термин, который недавно неприятно вошел в мой профессиональный лексикон. В нетривиальных масштабах отсутствие ясности убивает стартап: если нет ясности, никто точно не знает, что они должны делать, поэтому ничего не делается.
Интересно, что сегмент исполнителей стартапов, который больше всего страдает от отсутствия ясности, также является наименее обсуждаемым: компьютер.
Стартапы масштабируются с беспрецедентной скоростью в истории человечества, потому что компьютеры масштабируют выполнение с беспрецедентной скоростью в истории человечества.
К сожалению, компьютерам требуется абсолютная ясность, иначе они не могут ничего. Компьютеры настолько плохо справляются даже с малейшей долей двусмысленности, что нам пришлось создать специальные языки программирования и инструменты, чтобы устранить двусмысленность, когда мы делегируем им работу. Без четких, всеобъемлющих и последовательных требований нельзя использовать компьютеры для масштабирования бизнеса.
Поскольку компьютер абсолютно непреклонен в своих требованиях к ясности, теперь он становится бременем инженера. Без него их код не скомпилируется. Вот почему в большинстве стартапов инженеры больше всего ищут ясности.
Инженеры обычно находят способ скомпилировать свой код. Когда ясности не хватает, инженеры будут делать предположения.
В такой ситуации инженеры, которые очень привержены решению проблемы, будут вкладывать много времени и усилий, чтобы сделать правильные предположения.
Они проводят время за изучением рынка. Они изучают стратегию. Они глубоко разбираются в показателях. Они проясняют цели. Они разговаривают с покупателями. Они вовлекаются в операции. Работа по межфункциональному сотрудничеству. Они согласовывают заинтересованные стороны. Они создают видимость для руководства.
Они покроют все пробелы в продукте и в общем управлении, и, следовательно, они будут тратить мало времени на кодирование или совсем не тратить его.
Инженеры, менее заинтересованные в решении проблем управления, просто прочитают расплывчатую PRD / пользовательскую историю / заявку, заполнят все пробелы своим лучшим предположением и вернутся к написанию кода.
Первый результат на какое-то время позволяет добиться цели, но ослабляет ваши инженерные возможности, создает конфликт между функциональными направлениями и со временем создает второй результат. Второй результат превращает ваш продукт в уродливый, непоследовательный, глючный кусок дерьма.
Итак, что мы извлекаем из всего этого?
- Единственный человек, у которого есть серьезный стимул добиваться ясности в стартапе, - это инженер, потому что инженер должен делегировать выполнение компьютеру.
- Конечным результатом четкой бизнес-стратегии и четкого ведения бизнеса являются четкие требования к программному обеспечению.
- Если прояснение требований к программному обеспечению - это исключительно проблема инженера, вы начнете создавать инженеров-менеджеров - генеральных менеджеров, которые стремятся к необходимой ясности в требованиях, но не пишут код. Это отличается от инженерных менеджеров, которые являются экспертами в привлечении больших групп программистов к сотрудничеству для разработки кода и которым обычно требуется код для выполнения своей работы. Вы также сделаете менеджера по продукту несколько лишним.
- Если вы создадите не тот технический менеджер, будут сделаны неправильные предположения, будет написан неправильный код, и выполнение продукта остановится или даже завершится ошибкой.
