Классический источник напряжений и дисфункций в командах разработки — да на самом деле, в любых командах — это путаница между целями и ограничениями.
Команды часто ошибочно принимают ограничения за цели. Типичнейший пример: команда принимает требования к продукту за свою цель, теряя из виду реальные потребности, которые изначально породили эти требования.
Требования, архитектура, дизайн приложения — это ограничение. Как правило, одну проблему можно решить бесчисленным количеством способов, но мы просто выбрали один конкретный. Это по определению и есть ограничение.
Я видел много технических стартапов, которые теряли из виду, что, как и зачем они делают, и скатывались к 100-процентному фокусированию на добыче денег, необходимых исключительно на поддержание текущего состояния дел. Такое встречается очень часто. Подумайте о всех этих благотворительных фондах, которые начинали с чёткой цели (условно говоря, "спасти кота"), но спустя несколько лет вперёд оказывается, что большинство их усилий — если не все — направлены лишь на то, чтобы найти денег на то, чтобы выплатить всем зарплату и продолжать "благотворительность".
Конечно, вы можете возразить мне, что делать деньги — это и есть задача бизнеса, и эти деньги являются платой за то, что бизнес решает задачи пользователей. Цель ресторана — делать деньги. Цель ужина — быть съеденным. Я даю вам денег. Вы утоляете мой голод.
Поэтому, если вся суть существования вашей организации состоит в делании денег, то вам жизненно необходимо иметь хорошее, глубокое понимание целей и потребностей вашего клиента.
Такое представление о бизнесе идёт ещё из XIX века. Но даже тогда встречались прогрессивные промышленники, которые ставили цели большие, чем просто получение прибыли. В своём лучшем проявлении, компания может создавать смысл и цель для своих сотрудников, обогащать их жизни и жизнь сообщества, и добавлять привлекательности окружающему ландшафту.
Но я отвлёкся. Где я остановился? Ах да. Цели против ограничений.
Представьте, что вы планируете путешествие из своего дома в Лос-Анджелесе в Сан-Франциско. Ваша цель — посетить Фриско. Ограничением же может быть тот факт, что вы хотите ехать на своей машине, а бензина у вас не хватит на всю поездку.
Вы решаете добыть денег на бензин. Для этого вы начинаете делать лимонад и продавать его в киоске у своего дома. Дело идёт хорошо. Людям нравится ваш лимонад, и, благодаря удачному расположению вашего дома, около него всегда много прохожих, которым надо утолить жажду. Вскоре денег на бензин уже более чем хватает. Но продажа лимонада идёт так бойко, что вы только и заняты мыслями о нём, а не о Сан-Франциско. Вы планируете добавить в ассортимент свежевыжатый апельсиновый сок, а также смузи. Вы покупаете стол побольше. Вы нанимаете помощника, просто потому что не успеваете всё делать самостоятельно. Вы покупаете новый дом на этой же улице, крупнее и с более просторным двором. Затем вы начинаете поставлять свои напитки местным ресторанчикам, когда им не хватает собственных. Спустя 10 лет вы запускаете собственную сеть лимонадных киосков по всему городу.
Между тем, вы так и не побывали в Сан-Франциско. Да и сейчас вы слишком заняты, поэтому вряд ли найдёте время когда-нибудь съездить туда.
Теперь, если вы прожжённый капиталист, вы можете возразить: "и что?" Ваш лимонадный бизнес — это ли не достойная компенсация упущенному путешествию?
Может быть, да, а может быть, и нет. Становясь всё старше и старше, я всё чаще начинаю задавать себе вопрос "почему я делаю это?" Я знаю слишком много людей, которые слишком отвлечены "успехом" и никогда не ездили в путешествия, никогда не получали этот опыт, никогда не создавали домашнюю студию звукозаписи, никогда не могли выучить иностранный язык… и сделать всё остальное, что ещё было в их планах.
Для большинства из нас, равно людей и организаций, необходимость добывать деньги — это данность, от которой никогда не избавиться. Это ограничение, которое может помогать или мешать нам достигать своих целей.
Точно так же, в командной работе мы крайне легко опускаемся до деталей и перестаём обращать внимание на то, почему мы создаём программы и системы так же, как это делали изначально.
Поэтому я считаю, что здесь нужно искать баланс. Стараясь достичь цели, нужно уделять внимание имеющимся ограничениям, но если думать только о них и забывать про цели, то все наши усилия могут стать напрасными.
Слишком сильная привязка к ограничениям снижает наши шансы на достижение целей.
Ограничения ограничивают. В этом их суть. Например, если мы ограничили себя одним конкретным маршрутом из Лос-Анджелеса до Сан-Франциско, а на полпути обнаружили, что дорога перекрыта, то нам придётся искать другие способы достигнуть точки назначения.
Я не раз видел, как команды разбивали свои головы об стены, стараясь реализовать требования, которые по каким-либо причинам не могли быть выполнены. Слишком сложно оказывалось просто сделать шаг назад и напомнить себе, какой цели они хотели достичь, спросить себя "есть ли другой способ?". Я видел, как проваливаются проекты на многие миллионы долларов из-за того, что другого пути никто не видел. Это должен быть Oracle. Это должна быть Java. Это должен быть веб-сервис.
Нет. Не должен. Большинство ограничений, с которыми мы сталкиваемся, на самом деле являются чьим-то выбором — может быть, даже, выбором, который сделали мы сами — мы просто забыли, что это был выбор.
Конечно, постарайтесь сделать так, чтобы это работало. Но не путайте выбор с целью.
Примечание переводчика: меня зацепил этот текст, потому что он напомнил один старый спор с коллегой о том, как программисту следует относиться к требованиям к продукту. Коллега утверждал, что требование нужно реализовывать дословно, даже если оно неполное или не оптимальное. Я же пытался доказать ошибочность такого формального подхода. Возможно, думал я, эта статья добавит ещё один кирпичик в кладку моих аргументов.
Но в процессе перевода стало понятно, что автор затрагивает более сложную проблему. Зачастую инерция мышления приводит к тому, что мы раз за разом повторяем свои старые решения, даже не думая об альтернативах. Какую технологию использовать. Как строить процесс. Кто за что отвечает. Продолжаем делать всё как привыкли, ничего не меняя. Порой инерция помогает экономить силы, но она же может долго причинять боль и дискомфорт.
С аргументацией автора всегда можно поспорить, но один совет я считаю исключительно ценным: не забывайте поднимать голову и спрашивать себя "почему я это делаю? почему я делаю это именно так?"
Комментарии (31)
vadimr
08.05.2016 11:32+1Это вопрос управления требованиями. Изменение требований в ходе разработки — один из возможных путей. Но выполнять их, тем не менее, как правило, следует буквально.
svboobnov
08.05.2016 17:31+2Полностью поддерживаю. Жаль, не могу плюсануть.
По делу: Поставленную заказчиком (пользователем) задачу надо:
а) внимательно рассмотреть,
б) пометить в бумажке непонятные вопросы,
в) пойти к пользователю ногами (не письмом в электропочте, а, хотя бы, видеозвонком через Skype),
г) выяснить непонятки, или, ежели их много, выспросить у пользователя чего же он на самом деле хочет,
д) записать окончательное ТЗ на бумажку (лучше — с автографами обеих высоких договаривающихся сторон =)
е) Сделать точно по бумажке;
ж) протестировать;
з) Написать документацию;
и) отдать пользователю.
Вот при таком процессе вы полностью увидите картину: какие у нас на самом деле ограничения, какие у нас есть возможности, как мы можем сделать это быстро.
Если же сразу броситься кодить, принятые наспех решения и вложенные в эти решения усилия к концу задачи станут дополнительными ограничениями в задаче / проекте.
lpre
08.05.2016 16:50+2Насчет частой путаницы — это верно. Причем вот этот самый перевод привносит дополнительную порцию путаницы.
Типичнейший пример: команда принимает требования к продукту за свою цель
Реализация системы по требованиям к продукту, утвержденным заказчиком, и есть цель для исполнителя (разработчика). Если исполнителю кажется неуместной часть требований, то он может попытаться инициировать их пересмотр.
В оригинале более уместная формулировка:
A common example is when teams treat a design specification as a goal.
Обратите внимение, что речь идет не о functional (system requirements) specification, а о design specification.
Требования, архитектура, дизайн приложения — это ограничение.
В общем неверно, т.к. обычно только малая часть требований и деталей дизайна является ограничениями. В оригинале более правильно:A software design is a constraint.
Хотя и это не всегда так: обычно есть какие-то design constraints, но дизайн в целом не является ограничением. Он даже может меняться в процессе реализации без участия заказчика при неизменных исходных требованиях и ограничениях.
В целом, в зависимости от контекста, совет автора оригинальной статьи может быть как полезным, так и вредным советом: вы можете не только завалить многомиллинный проект, но и понести за это полную ответственность («Вы ограничения на дизайн в утвержденной спецификации видели? А что наваяли?!!! :-\»).
старый спор с коллегой о том, как программисту следует относиться к требованиям к продукту. Коллега утверждал, что требование нужно реализовывать дословно, даже если оно неполное или не оптимальное. Я же пытался доказать ошибочность такого формального подхода.
Ваш коллега был прав. Все эти спецификации — не что иное как формализация требований заказчика, потому и относиться к готовой спецификации следует формально. Свой творческий подход вы можете использовать на этапе анализа задач и сбора требований заказчика, но после утверждения просто выполнять его. А для внесения изменений есть свой формальный процесс.lpre
08.05.2016 16:57+1Впрочем, если заказчик и исполнитель — одно и тоже лицо (пусть и юридическое), то это меняет дело: даже полное изменение требований в уже начатом процессе разработки может быть гибким и простым делом.
zloddey
08.05.2016 17:22Спасибо за замечание. Действительно, с выбором перевода для слова design были проблемы. Перетасовывал без конца три варианта — дизайн, архитектура, требования — и остановился не на самом удачном. Возможно, стоит поправить текст перевода, пока не поздно.
В нашем споре с коллегой заказчиком, который создаёт спецификацию, являлся наш внутренний аналитик, поэтому, как Вы и добавляете ниже, смена требований в процессе разработки не вызывала никаких формальных сложностей. Вспоминая этот случай сейчас, я вообще склонен назвать его "итальянской забастовкой". Возможно, мой коллега тогда просто устал от самого процесса согласований и переговоров.
sshikov
09.05.2016 13:54+2Формализацию требований заказчика делают люди, и им свойственно ошибаться.
>А для внесения изменений есть свой формальный процесс.
Вот я лично для себя именно так и понял посыл данного текста — не нужно путать настоящие и формализованные цели. Если вы видите, что записанные на бумаге формальные требования противоречат в чем-то цели (которая обычно может сама быть записана в паре абзацев) — то самое время остановить реализацию этой формальной чепухи и запустить процесс внесения изменений.
Вот что никогда не следует делать — так это молча отступать от требований, просто потому что они видятся вам неполными.
atc
08.05.2016 17:26+4В статье обращаются к программисту, хотя обращение к стартап-холдеру было бы уместнее.
Точно так же, в командной работе мы крайне легко опускаемся до деталей и перестаём обращать внимание на то, почему мы создаём программы и системы так же, как это делали изначально.
С точки зрения программиста — для опыта и денег. А еще это весело.
В своём лучшем проявлении, компания может создавать смысл и цель для своих сотрудников, обогащать их жизни и жизнь сообщества, и добавлять привлекательности окружающему ландшафту.
Простите, но это маркетинговый булшит.
FDsagizi
08.05.2016 18:57+1Последние пол года у меня была цель 100 000$ оборот, на 2016 год. Командой 3 человека.
Недавно я убрал эту цель, осознал, что она только мешает
Зарабатывание денег это само собой разумеющиеся для нас приматов
Нельзя забыть про то, что надо зарабатывать
sirKrono
09.05.2016 13:54+2Мне одному кажется, что здесь больше воды, чем смысла? Чем то напоминает рассказы Пабло Коэльо о поисках истины и гармонии в жизни. Я предпочитаю более прагматичный подход — использовать ограничения, как вехи на своем пути. К примеру, три дня ты бьешься головой об стенку. Максимум три. Это ограничение. На четвертый осматриваешься по сторонам и находишь обходной путь. Идешь вперед. Но если ты продолжишь неограниченно биться об стенку, то это может отнять у тебя много времени впустую. С этой точки зрения ограничения помогают. А если же человек боится выходить за рамки своего кругозора и восприятия — это другое. Возможно, ему так проще жить. А если проще — зачем усложнять?
zloddey
09.05.2016 13:57Я думаю, это стиль такой у англичан и американцев — всё по три раза разжевать. Выглядит порой как вода, но кому-то, может быть, так более понятно. Мои собственные тексты страдают обратной тенденцией: максимально кратко изложить самую суть, не вдаваясь в подробности, мотивацию и т.п. В итоге порой потом ещё дополнительно объяснять приходится, что же имел в виду...
dTex
09.05.2016 13:54+2так это классикa — сначала в результате везения||хорошей команды||гениального руководителя организация вырабатывает политику, которая вписывается в рынок, идет прибыль, мерещатся радужные перспективы, но вдруг условия начинают изменятся и «мы все время так делаем» перестает работать, не полностью, но эффективность все меньше и меньше и да — политика организации становится главным ограничением, происходит «ритуaлизaция» методов работы и в точности как у жрецов пустыни Нaскa — рисунки богам все больше, a дождя все меньше. Эта тема хорошо рассмотренa в Теории ограничений Голдрaттa, я даже думал, что статья про нее.
mbait
09.05.2016 17:01+1Статья оторвана от контекста. В Долине есть куча аспектов, которые вместе и порождают эту невероятную гонку за прибылью. Есть ощущение, что там уже давно забыли, что существуют конечные пользователи, которые вообще-то и используют продукт. Если даже один из стартапщиков на момент остановится и подумает: "А что же действительно создаёт моя компания?", его в миг накроет лавина раздутых зарплат, раздутых рент, десятка конкурентов, желающих занять его нишу (ибо идея его стартапа нисколько не уникальна) и угасающего интереса инвесторов. А остальной мир просто пытается копировать с Долины. Кстати, "Фриско" уже давно "Сан-Фран" =)
Dovgaluk
10.05.2016 11:11+1Напомнило о книге «Ментальные ловушки. Глупости, которые делают разумные люди, чтобы испортить себе жизнь».
Там тоже часто предлагают не зацикливаться и пересмотреть свои действия.
Shamov
10.05.2016 11:23+1Можно добавить лишь то, что описанное представление о бизнесе идёт вовсе не из XIX века, а из религии под названием «протестантизм». Она намного старше. Протестантская трудовая этика предписывает человеку заниматься таким бизнесом, который наиболее угоден богу. А как определить, какой бизнес богу более угоден? Очень просто: это тот бизнес, который приносит больше денег.
В примере с торговлей лимонадом истинный протестант вместо того, чтобы расстраиваться по поводу того, что так и не побывал во Фриско, должен быть бесконечно счастлив от того, что ему удалось так хорошо реализовать божий замысел.zloddey
11.05.2016 09:33В целом верно. Единственная проблема в том, что "истинный протестант" — это абстракция, а статья обращена к реальным людям.
Shamov
11.05.2016 09:52Обидно, что в России статья настолько актуальна и вызывает живой отклик. По идее, поскольку протестантизм в нашей стране не имеет распространения, ценности у людей должны быть совсем иные. И такое представление о бизнесе, что будто бы его смысл в том, чтобы заработать денег, должно бы вызывать у людей лишь недоумение.
svboobnov
16.05.2016 15:07Так ведь мы воспитаны дикими телевизорами.
А дикие телевизоры предлагают две версии успеха:
* Известность + деньги;
* просто деньги.
YChebotaev
Мораль не очень ясна.
Ответ на вопрос:
Я так делаю, потому что это работает. Удивлюсь, если кто-то ответит иначе.
lair
Вы правда удивитесь, если кто-то вам ответит "я так делаю, потому что это требование заказчика"?
YChebotaev
Да. Заказчику ведь тоже нужно, чтобы это работало, вряд-ли он будет настаивать на том, что не будет работать. Да и вообще, странный какой-то заказчик, который вмешивается в технические детали, я был бы очень обеспокоен по этому поводу.
lair
Представление заказчика о том, что нужно для того, чтобы работало, не обязательно совпадает с представлением разработчика о том, что нужно, чтобы это работало. Иногда дело может доходить до того, что приходится сделать proof of concept точно по требованиям, чтобы доказать, что это не будет работать.
YChebotaev
Если заказчик лезет в технические детали, то просто игнорируйте такие советы. Если результат его устраивает, то и советы очень быстро иссякнут. А вот если результат так себе, то значит, это вы делаете что-то что не работает, тут тоже лучше обсудить с заказчиком и запросить дополнительные ресурсы. Если ресурсов не удастся выделить, то наверняка получится поменять задачу.
lair
А никто не говорит о советах, речь идет именно о требованиях.
YChebotaev
Это только слово страшное, а на самом деле — это просто фантазии заказчика на заданную тему. Если некоторые требования не будут соблюдены, но решение в целом приносит пользу, то никто не станет возмущаться.
lair
Эмм, то есть если в требованиях написана совместимость с MS SQL, а вы принесли пропиетарное решение на Oracle — никто не будет возмущаться?
YChebotaev
Нет, не будет, если вы об этом заранее договорились и вам выделили ресурсы на покупку оракла и заложили это в стоимость эксплуатации. Разумеется, если вы делаете что-то неожиданное, о чем не договаривались, то этому никто рад не будет, но это относится вообще ко всему, а не только к айти.
lair
Вот статья как раз о том, что если в требованиях написано MS SQL, то это не догма, а можно попытаться договориться на Oracle.
Другое дело, что договориться можно не всегда. И тогда в ответ на "зачем ты используешь здесь MS SQL, это же типичная задача для редиса" приходиться говорить "потому что это требования заказчика".
YChebotaev
Ну так вроде как это очевидно и без статьи, нет? Я думал, что там какая-то такая мораль будет, которую еще не все знают.
Звучит как какая-то тухлая отмазка. Мол, я не я и база данных не моя. Если MS SQL работает, и это хорошее решение, то зачем нужно говорить что это требование заказчика? А если он не работает, и редис решил бы эту проблему, то тогда нужно взять редис и говорить всем, что это хорошее решение, потому что так и есть.
lair
Не всем.
Кроме "работает" и "не работает" есть еще куча градаций, описывающих, грубо говоря, оптимальность выбора. Так вот, не всегда можно убедить заказчика, что ваш выбор оптимальнее, чем его выбор.
mphys
Очень Странный Заказчик (ОСЗ), который требует то что ему нужно!