Я начинаю пересказывать книгу Уильяма Детмера о теории ограничений, и попробую рассказать про все диаграммы.

Знакомство с диаграммами теории ограничений стоит начать с Критериев Проверки Логических Построений. Они описывают то, что мы в обиходе называем логичностью. КПЛП применяют к причинно-следственным связям на всех диаграммах, чтобы случайно не построить дерево параллельной реальности.

Вот небольшой чеклист КПЛП на основе книги Детмера. Я буду возвращаться к нему при дальнейшем пересказе.

• Ясность
  • Требуются ли дополнительные разъяснения по указанным причине и следствию?
  • Понятна ли связь между причиной и следствием?
  • Не пропущены ли промежуточные элементы между причиной и следствием?
• Наличие утверждения
  • Является ли высказывание законченной мыслью? Незаконченная: «Низкая скорость»; законченная: «Низкая скорость ведет к плохим результатам».
  • Есть ли в высказывании подлежащее и сказуемое?
  • В высказывании одно подлежащее и одно сказуемое?
  • Нет ли в высказывании неличных местоимений «кто», «это», «этот»?
• Наличие причинно-следственных отношений (если X то Y)
  • Действительно ли данная причина вызывает это следствие?
  • Звучит ли осмысленно в связке «если — то»?
  • Является ли причина измеримой и доказуемой? Нет: «начальник мной недоволен»; Да: «начальник не повышает мне зарплату».
• Достаточность
  • Вызывает ли причина сама по себе приведенное следствие, или должны быть еще причины? Пример с кислородом: «Если у нас есть источник тепла и горючее, то мы можем развести костер». На Луне построение неверно, потому что там нет кислорода.
• Проверка наличия альтернативной причины
  • Существует ли другая самостоятельная причина, ведущая к этому результату?
  • Если устранить приведенную причину, будет ли наблюдаться тот же результат при каких-либо условиях?
• Недопустимость подмены причины следствием
  • Может ли указанная причина на самом деле быть вероятным следствием? Нет: «Если у меня высокая температура и болит горло, то у меня ангина». Да: «Если у меня ангина, то у меня высокая температура и болит горло».
  • Не является ли указанная причина сигналом проявления, а не источником явления? Нет: «Если на берегу много рыбаков и их ведра полны рыбы, то сегодня хороший клев». Да: «Если на берегу много рыбаков и их ведра полны рыбы, то я понимаю, что сегодня хороший клев».
  • Может ли формулировка следствия быть просто сокращенным вариантом более точного утверждения?
• Поиск проверочного следствия
  • Наблюдаются ли еще какие-то обязательные проявления указанной причины? «Если аккумулятор разряжен, то машина не заводится», проверочное следствие: «стартер не срабатывает». Если стартер срабатывает, значит причинно-следственная связь — ложная.
  • Не наблюдаются ли проявления, которые опровергают указанную причину? «Если программист прикладывает мало усилий, то план сорван», проверочное следствие: «программист делает 20 коммитов в день». Если программист делает 20 коммитов в день, то он прикладывает много усилий, а значит план сорван по иной причине.
• Отсутствие тавтологии
  • Не приводится ли результат, как основание причины? «Спартак проиграл матч, потому что плохо играл. А почему они плохо играли? Потому что проиграли!»
  • Существуют ли еще какие-то следствия, которые подтверждают причину?

А вот упрощенный вопросник для быстрой проверки логических построений в устной речи.

37 сигналов — ребята, которые придумали делать софт без фич, запустили гениальный Бейскемп и написали Руби-он-рейлс. Все свои продукты они разработали без офиса. Недавно перечитал книгу «Remote: Офис не нужен», в которой они делятся опытом удаленной работы.

Успех проекта зависит от людей — чем выше уровень команды, тем лучше продукт. Чтобы заманить крутых людей, компании строят кинотеатры в офисе и платят огромные зарплаты. 37 сигналов пошли своим путем: отказались от офиса и разрешили сотрудникам самим выбирать фитнес-центр и кинотеатр.

Любишь бегать по лесу вместо беговой дорожки — пожалуйста, живи за городом. Нравится работать в толпе, — иди в кафе или коворкинг. Надоело — возвращайся домой. Работай хоть из республики Конго — главное поставляй вовремя результат.

Удаленную работу оценивают по результатам: неважно во сколько вы приходите на работу, как выглядите, используете вы мак или писюк. Когда все сидят в одном месте, трудно удерживаться от косвенных оценок. Типичный пример: симпатичная девушка систематически проебывает дедлайны, но задерживается каждый день на работе. Не у каждого руководителя хватит запала, чтобы принять жесткие меры. Или наоборот: замкнутый парень-программист на протяжении года ходит в офис в одном и том же свитере. К кому новички пойдут за советом — к нему, или к веселому соседу, который хоть и не разбирается в алгоритмах, но доброжелательно себя ведет?

Удаленная работа выгодна — не нужно тратить время на дорогу, отвлекаться на коллег, пытаться работать по 8 часов подряд (это же невозможно!). Для владельцев бизнеса удаленная работа — это работа на результат и отсутствие расходов на офисную девочку и корпоративные обеды.

В России не развита культура работы вне офиса. Это значит, что пока еще можно, как 37 сигналов, набрать сильную команду без огромных зарплат и бассейна в офисе. Достаточно разрешить им работать удаленно.

Читать больше:

• Лендинг книги на сайте авторов.
• Илья Бирман — Комьют. (И ответ от Евгения Степанищева).
• Тема — главный секрет удаленной работы.
• Алена Владимирская — почему удаленка не подходит для России.
• Николай Товеровский Удаленная работа vs Офис

На самом деле та интеллектуальная сфера, которая больше всего подходит для удаленной работы — копирайтинг, программирование, дизайн, консультирование и техническая поддержка (перечислять можно долго), — не имеет ничего общего с погоней за прибылью, характерной для, скажем, производства товаров.

Выдавливание из копирайтера большего количества слов в час никого не сделает богатым. А вот если он напишет отличное рекламное объявление, вас ждет успех.

Читаю крутейшую книгу Уильяма Детмера о теории ограничений. Пост о книге напишу как только разложу знания по полочкам, а пока не могу не поделиться прекрасным чеклистом.

Детмер предлагает использовать этот чеклист для демонстрации любых логических построений с помощью Мыслительных Процессов Голдрадта. Но кажется, что по нему стоит проверять вообще любые обсуждения производственных нововведений с проектной командной.

• При составлении диаграмм разработчики опираются на логику.
• Разработчики диаграмм представляют их команде и участвуют в обсуждении последующих необходимых действий.
• Разработчики диаграмм небезралзличны к своим творениям и заинтересованы в их применении.
• Разработчики диаграмм показывают команде не только сами схемы, но и использованную при их построении логику.
• Разработчики не предоставляют команде логически слабые построения.
• Презентацию диаграмм проводят не только, чтобы получить молчаливое одобрение команды, но и чтобы услышать конструктивные советы и свежие идеи.
• Участники обсуждения способны воспринимать конструктивную критику в адрес выдвинутых ими логических построений.
• Участники обсуждения способны и стремятся принять конструктивный совет, если он высказан не в агрессивной форме: не «я против тебя», а «мы с тобой против системы».
• Приглашенные эксперты должны быть заинтересованы в командной работе над изучаемой проблемой.
• Приглашенные эксперты не должны ставить себе целью оскорбить разработчика или самоутвердиться за его счет.
• Приглашенные эксперты должны быть специалистами в предметной области, к которой относится изучаемая проблема.
• Координаторы работы концентрируются на логике представляемых схем, а не на содержании составляющих эти схемы элементов.

Пока я осваивал технику пустого инбокса, завел себе вредную привычку, которую отловил только недавно. Спешу поделиться правилом — не храните задачи в почте.

Книги по тайм-менеджменту говорят, что нужно вести только один список задач. Нельзя одновременно хранить задачи в календаре, напоминалках и на стикерах возле монитора. Это сбивает с толку быстрое мышление — ленивый мозг в процессе работы над плановой задачей натыкается на какие-то неактуальные напоминалки страдает и пытается на них переключиться. А облегчить страдания ленивого мозга может только привычная прокрастинация.

После перехода на пустой инбокс, когда в ящике становится меньше 10 000 писем, почтовый клиент начинает работать как монитор со стикерами:

1. залезаем в почту, чтобы найти старое письмо от клиента;
2. видим письмо о подарке коллеге на свадьбу, которое не удалили, чтобы не забыть скинуть 100 рублей;
3. задумываемся о подарке;
4. просыпаемся в компании котиков из фейсбука.

В моем случае копились письма-цели: долгие задачи вроде согласования документов или сложных фич на проектах. На удаление этих писем стояла какая-то внутренняя блокировка: как же, ведь это письмо от Самого Главного! Задачи из таких писем я не добавлял в задачник, a хранил во входящих. Мой пустой инбокс никогда не был по-настоящему чистым — всегда оставалось 3–4 письма, которые я привычно игнорировал. Только отвлекался на них несколько раз в день, чтобы вспомнить от кого они и зачем.

Привычка исчезла как только я 2 раза за неделю применил почтовое банкротство — удалил по 40–50 писем не читая, чтобы не размывать фокус. И, представьте себе, небо не упало на землю — все, кому действительно было что-то от меня нужно, не поленились и написали еще раз. Документы не потерялись, цели не сместились дедлайны не проебались. Не произошло вообще ничего!

Почтовое банкротство похоже на кровопускание — по неосторожности можно и убиться. Но мне оно помогло победить старую вредную привычку.

В экосистеме разработчиков под Ай-ос хуёво всё — подписание кода тестирование, публикация, управление витриной. Наверное дизайнеров специально не допускают к проектированию экосистемы, чтобы программисты отдохнули от них и сделали что-нибудь с красивой архитектурой.

Чтобы выпустить приложение, нужно сначала дождаться разрешение от Эпл. Над разрешением они думают не меньше недели и никак не гарантируют срок ответа. Идеальный способ избавиться от этой неопределенности на своем проекте — сделать предварительную сборку приложения без фич и за 3–4 недели до релиза отправить ее на модерацию. Эту сборку выпустит ваша команда, если вас вдруг собьет автобус.

После того, как Эпл вынесет резолюцию о судьбе вашего приложения (это если вы конечно, нашли незаметную галочку «не выпускать приложение сразу после модерации», и оно сразу не пошло в народ), нужно принять решение — или выпустить, или отменить релиз. Если отменить, то останетесь без релиза (результат модерации аннулируется). Если выпустить — люди увидят сырую сборку раньше срока. Если оставите в подвешенном состоянии — потеряете возможность тестировать через Тестфлайт (напишу отдельный пост о том, что с этим делать).

Способ не запускать продажу готового приложения так же неочевиден, как и все остальное в айтюнс коннект — нужно зайти в управление ценами (пункт Pricing) и отключить продажу для всех возможных стран. Тогда статус у приложения станет красным — «Developer Removed from Sale», и вы сможете добавить следующую версию приложения, пока никто не видит предыдущую.

Апдейт

Эпл обновили внешний вид Коннекта, и теперь стало легче: