«Один из самых лучших способов избежать неприятностей — упростить их. Когда вы очень усложняете проблему — и только несколько первосвященников в каждом отделе могут притвориться, что понимают её — чаще всего вы обнаружите, что эти первосвященники вообще ничего не понимают… Такая система часто выходит из-под контроля», — Чарльз Мангер
Многие бизнес-проблемы возникают самопроизвольно. Многие раны наносятся самому себе. В конкуренции можно выиграть, но чаще всего конкурент проигрывает себе же.
Предприниматели очень хорошо умеют всё для себя усложнять. Я говорил со многими из них и вижу это повсеместно. Если бы они только приложили больше усилий, чтобы избежать будущих проблем, а не решить текущие, которые создали себе перед этим, то могли бы достичь существенно большего прогресса за меньшее время.
Мы построили наш бизнес на том, чтобы избегать проблем. Это фундаментальная причина, по которой мы способны делать то, что делаем, и продолжаем заниматься этим — с прибылью, и с маленькой командой — на протяжении 18 лет. Всякий раз при принятии важных решений мы оцениваем их последствия. В целом, вопрос стоит так: насколько всё будет плохо, если мы сегодня сделаем это?
Мы не ищем славы в борьбе с трудностями. Мы предпочли бы сделать очевидный выбор и вообще избежать предсказуемых проблем.
Вот некоторые примеры, чего мы избегаем:
Роста
Мы специально сохраняем Basecamp небольшим. Обслуживая более 100 000 платных клиентов и несколько миллионов пользователей со штатом чуть более 50 человек. Маленькие фирмы избегают проблем, которые есть у больших компаний. Меньше менеджеров, меньше слоёв управления, меньше потерь при передаче информации, значительно меньше узких мест и формальных процессов, из-за которых людям приходится ожидать разрешения, чтобы приступить к чему-нибудь. В компаниях меньшего размера всё проще и каждый сотрудник ближе к потребителям. Конечно, некоторые маленькие компании не способны на то, что могут сделать большие, но с нашей точки зрения это очень хорошо.
Больших коллективов
Мы специально удерживаем численность штата, в том числе формируем команды намеренно малого размера. Почти каждый проект в Basecamp делает команда из трёх человек или меньше (два программиста, один дизайнер), а существенное количество групп состоит из одного человека (программист или дизайнер). Можем ли мы решать более существенные задачи с большими командами? Может быть — но при этом крупные команды создадут и более крупные проблемы. Орвчинка не стоит выделки. Нам нравится делать много маленьких проектов меньшими группами. Мы по-прежнему добиваемся всех поставленных целей — просто более мелкими шажками. Это облегчает корректировку курса по пути. И, честно говоря, это в любом случае лучший способ работы.
Долговременных целей
Сложно найти что-то более деморализующее, чем долгосрочный проект, которому не видно конца. Хотя время от времени случаются инфраструктурные проекты без конечной даты, но почти всё, что мы делаем, укладывается максимум в шестинедельные циклы (я подробно писал об этом раньше). Многие проекты намеренно сокращены, чтобы уложиться в несколько дней или пару недель. Так что даже если мы выделили 6 недель на какое-то дело и недовольны результатом — мы потеряли всего лишь 6 недель. Мы избегаем всех осложнений, которые появляются при попытках всеми силами дожать сомнительные проекты. Сравните это с проектами, которые описываются фразами «слишком крупный, чтобы провалиться», «будет завершён, когда сделаем», и они продолжаются 6, 8, 12 и более месяцев… Вряд ли вы откажетесь от результатов работы, когда её закончат. Длительные проекты — могилы боевого духа.
Планов и обещаний
Аналогично предыдущему пункту, мы не заглядываем в будущее дальше, чем на 6 недель. У нас есть некоторые идеи общего характера, куда мы хотим развиваться, но эти идеи мы держим в голове и редко записываем. Это неофициальная устная традиция. Также мы редко даём обещания насчёт будущего. Такие обещания — богатый источник головной боли и конфликтов. Легко дать согласие на нечто в будущем, потому что это не требует усилий прямо сейчас. Но когда наступает время, вы вряд ли захотите делать то, что обещали давным-давно. Прошлые обещания — источник большого количества проблем в бизнесе. Мы бежим от таких обещаний как от чумы. На эту тему я тоже раньше писал.
Масштабирования
Масштабирование! Масштабирование! Все хотят масштабироваться А МЫ НЕ ХОТИМ! Мы стараемся избегаем проектов, обязательным условием которых является масштабирование. Мы ищем проекты, которые будут успешными в любом масштабе — малом или большом. Для большинства компаний масштабирование — синоним того, что сейчас концы с концами не сходятся, но со временем они сойдутся. Не бегите впереди паровоза — растите разумными темпами. Выходите в плюс как можно раньше с минимальным количеством клиентов, а не с воображаемым множеством.
Грозных дедлайнов
У нас есть дедлайны, но мы избегаем грозных дедлайнов. Это такие дедлайны, которым наплевать на вас. Они заставляют торопиться и бежать, но продолжают дразнить фальшивой финишной чертой. Это не то, к чему вы стремитесь. Что ещё хуже, вы не только не видите финиша, но необязательно это будет настоящий финиш, если вы его увидите. «Нужно поднажать ещё», «мы никогда не сделаем это в срок...». Настроение падает, качество страдает, а люди стремятся просто сдать проект, а не выполнить его качественно. Пропадает всякое удовольствие, если вы постоянно отстаёте от расписания.
Недопонимания
У компаний не бывает проблем с пониманием, у них проблемы с недопониманием. Каждый лишний человек, которого вы добавляете в беседу, увеличивает риск. Как говорил Осмо Вио, понимание обычно недостижимо, разве что по случайности. Малые компании и малые группы по своей природе имеют преимущество в коммуникации над большими. Конечно, два человека могут не понять друг друга, но это чистая математика: малые команды, малые группы, малые компании значительно увеличивают шансы на корректную передачу информации, по сравнению с большими.
Партнёрства
Большие компании постоянно предлагают нам сотрудничество. Они хотят стать нашими партнёрами. «Нам интересно, хотите ли вы заключить партнёрские отношения по какой-нибудь теме»… Большой красный флаг. Раньше мы поддавались на такие предложения и они всегда заходили в тупик. Большая потеря времени. Это особенно справедливо для несбалансированных ситуаций, когда огромная компания хочет сотрудничать с маленькой. Учитывая все обстоятельства, обычно всё сводится к гигантскому объёму работы для вас (маленькой компании) и крошечному объёму для одного из их сотрудников, которому не нужно самому ничего исполнять. Уходите от этого!
Узких мест
Мы избегаем вещей, которые останавливают информационный поток и тормозят движение вперёд. Не создаём структуры управления или правила, которые требуют получения разрешения. Пока то, что ты делаешь, не может уничтожить компанию — просто делай это. В роли бутылочного горлышка может выступать человек, процесс, оформление документов, получение разрешения. Мы предпочитаем, чтобы процесс шёл своим чередом, а не останавливаться и проверять на каждом шагу. Естественно, в таком ключе что-то может пойти неправильно, но такое случается редко, гораздо чаще всё идёт как надо, без проблем. Ноа раньше писал об этом.
Может и странная метафора, но я всё равно скажу… Это как мыть посуду после еды. Если ты кушаешь и сразу после еды моешь посуду, то никогда ничего не нужно мыть потом. Вы избегаете трудностей и дополнительной работы в будущем. Если же сложить грязные тарелки в кучу, то в реальности вы создаёте больше работы для самого себя — или для кого-то другого. Остатки еды засыхают, пригорают, их труднее отчистить. Вы увеличиваете уровень сложности работы. В дальнейшем груда посуды начинает пугать — зачастую она растёт просто потому что каждый боится за неё взяться. Что такое ещё одна грязная тарелка? Просто брошу её туда. Но если вы моете посуду после еды, то всё происходит гораздо быстрее, это как часть процесса приёма пищи (а не отдельная процедура), и вы никогда не будете возвращаться к этой работе — она уже сделана. Будущее свободное и чистое.
Не оставляйте грязную посуду на работе.
Комментарии (22)
dimkss
13.07.2017 10:51Меня вот этот абзац смутил:
>> Если бы они только приложили больше усилий, чтобы избежать будущих проблем, а не решить текущие, которые создали себе перед этим, то могли бы достичь существенно большего прогресса за меньшее время.
Какое-то слишком сильное обощение.
Надо иметь очень большой опыт (предвиденье?) чтобы знать каких именно будущих проблем нужно избегать. Как там классики говорили «преждевременная оптимизация — зло», «не дайте себя запутать, астронавтам архитектуры» и тому подобное.
Насколько я понял они решают это тем что берут только отобраные проекты, с развитием которых они более менее знакомы. М-м-м… но это как-то слишком просто, нет?
greendimka
13.07.2017 11:48Надо иметь очень большой опыт (предвиденье?) чтобы знать каких именно будущих проблем нужно избегать. Как там классики говорили «преждевременная оптимизация — зло»,
В моей компании утверждение «преждевременная оптимизация — зло» — как раз таки зло. И продукты годами работают без багов. А вот подход «починим/оптимизируем потом» никогда не работает. Потому-что «потом» никогда не наступает.dimkss
13.07.2017 12:02Я подозреваю что у меня слишком мало опыта для преждевременной оптимизации что скорости, что структуры даных, что связей.
Почему-то после большинства попыток оптимизаций появляется новое требование заказчика, котороехеритуничтожает эту попытку, и приходится впопыхах все переделывать.
Утешает то, что я замечал это и за разработчиками фреймворков, и либ, и всеми-всеми, где проекты хоть чуть-чуть сложные )
Конечно какие-то оптимизации нужны. Понятно что лучше использовать (я упрощаю) базу данных для хранения инфы о пользователях вместо файла, но вот дальше…
SirEdvin
13.07.2017 12:14Мне кажется, вы не совсем правильно его понимаете. Это выражение не говорит о том, что вообще не нужно оптимизировать. Но то, что нужно выбирать решение оптимальное по соотношению затраты<->производительность<->поддерживаемость, а не только по производительность.
AstarothAst
14.07.2017 16:25Сдается мне проблема тут не в том, что злом является преждевременная оптимизация, а в том, что «потом» никогда не наступает.
Xandrmoro
13.07.2017 12:11Сложно найти что-то более деморализующее, чем долгосрочный проект, которому не видно конца.
Как-то спорно. Меня, например, наоборот деморализовало, когда меня бросали между проектами каждый месяц, зато работать на одном и том же большом проекте три года — всегда пожалуйста (если он достаточно большой, чтоб можно было раз в полгода-год менять специализацию работы).SirEdvin
13.07.2017 12:15И что, у вас там совсем не было сроков, vision и прочих штук?
Там важное уточнение, что "не видно конца". Думаю, тут имеется виду, когда у вас проект настолько большой, что вы даже не знаете, когда он будет готов, а только пилите, пилите и пилите.Xandrmoro
13.07.2017 14:55Высший менеджерский состав рассчитывает на активный лайфтайм не менее пятнадцати лет.
Есть некие условные «фазы», которые длятся в среднем около года, но в целом — пилим, пилим и пилим. Наметили майлстоун — пилим, допилили — наметили следующий.SirEdvin
13.07.2017 15:29Ну так у вас видно конец. Понятное дело, что если компания продуктовая или аутсорс у продуктовой компании, то пилить будете пока есть компания.
Другое дело, что это не выглядит так, как будто не видно конца. Всегда понятно куда и откуда двигатся. А бывают случаи, когда это совсем не понятно.
evpers
16.07.2017 16:48Сначала удивило:
«У нас есть некоторые идеи общего характера, куда мы хотим развиваться, но эти идеи мы держим в голове и редко записываем.»
А потом понял: они один раз приняли решение на будущее, чем в принципе хотят заниматься.
И теперь, регулярно, но понемножку, приспосабливаясь к изменениям в мире, не чувствуют на себе довлеющих обязательств пятилеток ).
Молодцы. Поверил, что в их нише это работает.
По поводу узких мест и мыть посуду после еды — большое спасибо!
Я на работе поначалу пытался с утра делать как можно больше срочных дел, чтобы разгребаться после обеда.
Так как надо сначала дать ответ контрагенту, а уже потом можно внести данные в базу, сначала надо сделать и отдать в работу аналитику и заказ, а уже потом зарегистрировать их…
Но, как оказалось, что даже промежуток в полдня заставляет потом тратить на эту зачистку хвостов намного больше времени, чем когда задача делается целиком.
После переосмысления теперь немного упираюсь, когда пытаются навесить несколько новых срочных задач, пока не доделал предыдущие. В большинстве случаев руководство понимает и соглашается. В 20-30% случаев срочность новых «вводных» перевешивает, и приходится-таки откладывать доделывание на потом. Но и отвоёванные 70-80% позволяют гораздо меньше уставать в течение дня. Как бы меньше незакрытых вопросов одновременно висит в голове, от этого легче.
Спасибо за статью!
x07
Могу ошибаться, но так делается во всех небольших компаниях, нанимают одного программиста за 2 копейки из колхоза, и вешают на него все: администрирование серверов, обслуживание орг техники в офисе, фронтенд, бекенд, администрирование и проектирование БД, написание тестов для всего и т.д.
С точки зрения бизнеса, это выгодно — оптимизируются расходы и избегается проблема роста. Но это порождает множество других проблем связанных с качеством продукта, скоростью исправления багов, обслуживания, разработкой нового функционала и т.д, а руководитель, как правило считает, что это не его ошибка, а плохая работа подчиненных.
saterenko
Мне кажется, автор имел ввиду не один человек, который делает всё, а минимальная команда, которая делает конкретный проект. При чём тут оптимизация расходов и эникейшик? Если проект на столько простой, что его может сделать за полтора месяца пара рубистов (они вроде руби любят), зачем нужно больше?
SirEdvin
Потому что на проекте все равно нужен кто-то, кто будет выполнять роль PM, BA, QA, UI/UX дизайнера, Архитектора, Админа и прочее.
И если у вас команда из 2-3 человек, это валится на кого-то одного из них)
saterenko
Вы по ссылкам ходили? У них там хорошо описан процесс, с примерами… Не нужно в ИХ проекте то множество аббревиатур, которые вы написали…
SirEdvin
Не бывает "не нужно".
Тут или эти роли выполняются кем-то на много проектов сразу, или же они выполняются кем-то из людей в проекте.
Возможно, я не прав, но я пока придерживаюсь такой позиции.
Если у них все нормально работает, значит у них первый вариант и они немного лукавят, насчет размера команд.
RomanArzumanyan
Не факт. Полно таких небольших, но важных проектов, где лучше всего иметь команду из 2-3-4 senior'ов. Это могут быть feasibility, proof-of-concept проеты, исследования, платные доработки для конкретного клиента…
SirEdvin
Это сложно назвать проектом, это обычно отдельные задачи.
Я не прав?
RomanArzumanyan
Бывают разные. Если задумка инженерно сложная, то feasibility может стать в 36 человеко-месяцев или около того. 1-2 исследователя, столько же программистов. Если взлетает — тогда большая команда берётся за продуктизацию.
Не знаю насколько это распространённая практика, но мне доводилось участвовать в подобных проектах не раз.
saterenko
Ого, сколько тут обиженных эникейщиков и ленящихся почитать ссылки из статьи… Удачи вам )))))