Принципы getting real

13.04.15, 14:15Принципы Getting Real (Часть 1) / Мегамозг

Страница 1 из 22http://megamozg.ru/post/14152/

Принципы Getting Real (Часть 1)Продолжаем читать хорошие книги вот из этого списка отMilfgard и я продолжаю писать конспекты. Сегодня это,пожалуй, одна из самых важных книг в жизни IT-специалиста:Getting Real от 37signals. Она переворачивает мозги и даётпрекрасные рабочие принципы организации работынебольших компаний.

Пока читал эту книгу, я прямо мягким местом ощущал, чтоделал неправильно, и видел, как то же самое можно было бысделать намного лучше. Кстати, я планировал уместить веськонспект в одну статью, однако книга оказалась настолькоконцентрированной, что просто убрать воду и выделитьглавное не получилось. Книга построена таким образом:{принцип + описание принципа + пример}. И так много-многораз, так что много сократить не получилось и пришлосьразбивать материал на две статьи. Итак, приступим.

http://habrahabr.ru/company/mosigra/blog/110797/

http://megamozg.ru/users/milfgard/



1. Делайте меньше

Сделайте меньше, чем ваши конкуренты. Если у вашихконкурентов есть 1000 функций, — сделайте 100 или даже 50.Решите базовые простые проблемы и оставьте решениесложных всем остальным. Это значит:

Меньше возможностейМеньше настроекМеньше компанияМеньше встречМеньше обещаний

2. Делайте ПО для себя

Если вы решаете собственные проблемы и становитесь длясебя потенциальным клиентом, соответственно, и знание отом, что нужно у вас тоже есть. Знайте, что вы не одни: если увас есть какая-то проблема, то такая же есть ещё у сотни или утысячи человек. Когда вы решаете собственную проблему, выделаете инструмент с душой. А это значит, что продукт точнобудет успешен.



3. Финансируйте себя сами

Если вы привлекаете инвесторов, вы несёте перед нимиответственность. Инвесторы быстро захотят вернуть своиденьги и, как результат, вы будете думать больше о быстрыхденьгах, чем о хорошем продукте. Чтобы уложиться вминимальный бюджет вам просто нужно начать работать не с10 людьми, а с тремя. Расставьте приоритеты и подумайте, чтовы можете сделать с тремя людьми? Это реально будетглавный функционал, который, вообще-то и нужен.

4. Используйте ФФФ

«ФФФ» — fix time, fix budget, flex scope. Сделать проект сзапланированной функциональностью к определённой дате заопределённые деньги нереально. Какой выход?Зафиксировать только два из параметров. Парни из 37signalsпредлагают зафиксировать время и деньги и оставитьоткрытый скоуп. Если вы не можете сделать вовремя экраннастроек, — избавьтесь от этого экрана и не делайте его. Болееподробно о применении ФФФ в студии Артёма Горбуноваможно читать тут.

Чтобы успешно работать по ффф, вам потребуется расставитьприоритеты и определить, что действительно важно для

http://bigplans.megaplan.ru/fff



продукта. Ну и гибкость тоже пригодится.

5. Придумайте себе врага

Найдите монструозное ПО от конкурентов и сделайтепротивоположное. Когда 37signals решили работать надBasecamp, они выбрали в качестве «монстра» MS Project ипостарались сделать намного меньше, но гораздо лучше. Когда вы выбираете врага, это даёт вам возможность сказать,чем конкретно ваш продукт лучше, чем он отличается. Людибудут сравнивать и поверят вам, если ваш продуктдействительно хорош. Тщательно анализируйте другое ПО итолько потом двигайтесь к собственному видению исобственным идеям.

6. Никакой рутины

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



счёт упрощения рутинной операции.

7. Страсть

Делайте продукт с душой и это заметят. Ничто так не огорчает,как бездушный продукт. С другой стороны, когда вы видите,что разработчики делали продукт с душой и уделилидостаточно внимания вашему пользовательскому счастью, выбудете довольны. Это, кстати, очень хорошо видно винструкциях. Сравните тур по basecamp с туром по MsProject ипочувствуйте разницу в отношении авторов к своей работе.

8. Оставайтесь маленькими

Для того, чтобы остаться маленькой компанией нужноизбегать следующего:

Долгосрочные контрактыБольшой штат сотрудниковНеизменные решенияСовещания о других совещанияхДолгий процессОбширный инвентарь (физический или умственный)Привязка к оборудованию или программамЗакрытые форматы данных

https://basecamp.com/tour

https://support.office.com/en-ca/article/Getting-started-Microsoft-Project-basics-56cc59a0-2315-4b1e-b268-935b48357942



Управление будущим на основании прошлогоДолгосрочные целиОфисная политика

Уменьшить компанию позволяют:

Решения, принимаемые по мере надобностиМногозадачность членов командыУстановка ограничений, вместо попыток их преодолетьУменьшение программного обеспечения, меньше кодаМеньшее количество функций продуктаМаленькая командаПростотаОткрытые исходные кодыОткрытые форматы данныхСвободная атмосфера, в которой легче признавать ошибки

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

9. Непредсказуемость

В вашем продукте могут внезапно появиться новые свойства.Они не проектируются и не строятся; они просто случаются.



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

10. Три мушкетёра

Используйте команду из трёх человек в первой версии. Этодостаточный ресурс, который позволяет быть быстрыми ипроворными. Начинать можно с разработчиком, дизайнероми человеком, который разбирается и в том и в другом.Талантливым людям не нужны бесконечные ресурсы, у нихесть энтузиазм.

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



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

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



11. Принимайте ограничения

Когда 37signals делали Basecamp у них было многоограничений. Они начинали, как дизайнерская фирма стекущей клиентской базой с 7-ми часовой разницей вовремени с одним из разработчиков. У них была маленькаякоманда без внешнего финансирования. Но они принялиограничения, взяли большие задачи и разделили их намаленькие куски, чтобы попытаться выполнить их по одному.Разница во времени стала серьёзным факторомкоммуникации и вместо встречи они связывались почтиисключительно через мессенджеры и электропочту.

12. Всегда и в любое время

Хорошее обслуживание клиентов обязательно должно быть. Ине важно, в каком вы бизнесе. Сделайте так, чтобы клиентымогли связаться с вами по любому вопросу. Укажите на сайтеваши почты и телефоны. Сделайте упор на то, что клиентымогут добраться до вас и связаться в любое время. Клиенты37signals ценят этот уровень доверия и никто никогда им незлоупотреблял.

13. Приоритеты



Ясно и точно определите видение для вашего приложения.Что оно должно делать? Почему оно должно существовать? Вчём отличия от аналогов? Это видение будет вести вас поправильному пути и каждый раз, когда у вас будут сомнения,— посмотрите на видение и вы увидите, что делать. ВидениеBasecamp звучит так: «Управление проектом — этокоммуникация».Это видение позволило сделать так, чтобыBasecamp стал максимально открытым и прозрачным. Вместонавязывания ограничений в Basecamp дали доступ клиентам.

Можно было бы сделать электронные таблицы, графики,диаграммы, статистику, но они сосредоточились наприоритетах коммуникаций: комментариях, списках ираспределении файлов.

14. Пренебрегайте деталями в начале

37signals пишут, что для них очень важны детали:пространство между объектами, совершенный цвет,совершенные слова, четыре линии кода, вместо семи, и т.д. ит.п. Успех и удовлетворение находятся в деталях, однако тамже вы найдёте и застой, разногласия, встречи и задержки. Этивещи могут уничтожить весь проект. Если вы сидите надодной строчкой кода в течение целого дня или работа,сделанная за целый день не дала никакого прогресса, значит,



вы слишком рано сосредоточились на деталях. Не волнуйтесьо пикселях, размере шрифта и совершенной тени, а простопоставьте материал на страницу и убедитесь, что оно работает.Позже вы сможете всё усовершенствовать.

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

Всегда работайте от большего к меньшему. Всегда.

15. Не тратьте время на проблемы, которых ещё нет

А что же будет, когда на наш сервис зайдут 100000 человек? Анужно ли нам 12 серверов, если хватит всего двух? Не нужнорешать проблемы, которых у вас ещё нет. Нужно простососредоточиться на главном и, если рост количествапользователей будет только через два года, — займитесь этимчерез 1 год и 9 месяцев. Это значит, что вам просто нужнопринимать решения вовремя, имея всю необходимую дляэтого информацию. Знайте, что в любом случае вам придётсяпереписать вест код рано или поздно.

Случай из собственной практики. Когда мы пытались сделатьпроект t-menu (электронное меню для ресторанов) и успешно



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

16. Работайте с правильными клиентами

Нужно найти основной рынок для вашего продукта исконцентрироваться исключительно на нём. Если выориентируетесь на всех, — вы не ориентируетесь ни на кого.Basecamp сделан для дизайн-студий. Сузив рынок 37signalsувеличили вероятность привлечения страстных клиентов,которые, в свою очередь, проповедовали продукт какЕвангелие.

17. Выбор функций

Создайте половину продукта, но пусть это будет законченныйпродукт. Вы можете что-то не выпускать в релиз, но всё самоеважное, сердце продукта, должно работать. В Basecamp



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

Сделайте добавление функций трудноосуществимой задачей.Каждый раз, когда вы решаете добавить новую особенностьили возможность, вы принимаете ребёнка. Если запрос нафункцию постоянен, можно прислушаться, но не сразудействовать. Как только будет видение, как эта новая функциябудет работать в реальном окружении, — можно делать.

Вы должны понимать скрытые затраты на новые функции.Например, вы добавляете в бэйскемп таблицу встреч. Дляэтого вам нужно знать место, время, список людей, сделатьприглашения по электропочте, календарь, интегграцию сgmail, обновить документацию, сообщить в техподдержку какэто работает. Придётся обновить скриншоты в руководствах,страницы тура, условия обслуживания и т.д. Подумайте,сколько эта небольшая функция принесёт головной боли. Такчто для каждой новой функции вы должны пройти следующиеэтапы:

Сказать «нет»Вынудить функцию доказать своё значение. Если снова«нет», значит не нужно делать. Если «да», — продолжайте



Сделайте эскиз экрана/интерфейсаСпроектируйте экран/интерфейсЗакодируйтеИспытаниеПроверка текста помощиОбновите ознакомительный тур продуктаОбновите маркетинговую копиюОбновите условия обслуживанияПроверьте, были ли затронуты предыдущие обещанияПроверьте на то, как это воздействует на общую структуруЗапустите и затаите дыхание

Вообще, забудьте о запросах функций. Т.е. не то чтобы совсемзабудьте, а просто принимайте их, читайте, но ничего неделайте, пока функция не созреет. Если функциядействительно важна, пользователи не дадут вам про неёзабыть. Вместо того, чтобы спрашивать у людей, что онихотят, спросите у них что они не хотят. «Скажите, какимифункциями вы не пользуетесь?» или «Если бы вы моглиубрать одну особенность, что бы это было?». Побольше «нет»в вопросах.

18. Создавайте ПО для общих решений

Не навязывайте людям свои решения. Предоставьте людям



инструмент, с помощью которого будет достаточно просторешить их собственные проблемы. Например, если вы хотитедобавить категорию к названию todo, вы можете простодобавить её в квадратных скобках: [Request]. Если хотите,чтобы исполнитель писал, сколько он времени потратил назадачу, — пусть исполнитель пишет затраченное время вкруглых скобках в конце названия todo: «Вёрстка главнойстраницы (8ч)».

Сделайте решения базовых задач, а люди найдут собственныерешения в пределах вашей общей структуры.

19. Работайте итерационно

Не ожидайте того, что будете понимать и делать всёправильно с первого раза. Пусть приложение растёт в боевомрежиме. Проектируйте, используйте, анализируйте,переделывайте и запускайте снова. Вы будете приниматьинформированные обоснованные решения; у вас всегда естьобратная связь и реальное понимание того, что требует вашеговнимания.

Если вы знаете, что собираетесь переделать всё снова, вам ненужно нацеливаться на совершенствования при первойпопытке. Вот подход, который изпользуют в 37signals:



1. Мозговой штурм. Что этот продукт будет делать? Какиепотребности? Как мы будем знать, когда это полезно? Чтоточно мы собираемся делать?

2. Бумажные эскизы. Быстрые и простые эскизы — этохорошо и экономно. Цель: превратить мысли в набросокинтерфейса.

3. HTML-макеты. Сделайте то, что будет отдалённонапоминать программу на экране.

4. Закодировать. Сделайте так, чтобы HTML зажили изаработали. Тут главное сразу исключить плохой инепродуманный код. В остальном ориентируйтесь на то,что вас ждут многократные повторения.

20. Избегайте настроек

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



В текстовом редакторе EmEditor так много настроек, чтохочется плакать: 15 вкладок по 10-15 контролов.

Просто сделайте выбор и примите простые решения. Числосообщений на страницу — 25, сообщения сортируются вхронологическом порядке, пять последних проектоввыводятся на dashboard. Вариантов выбора настроек нет.

Возможно, вы сделаете плохой выбор, но это не смертельно:люди будут жаловаться и вы очень быстро об этом узнаете.Всегда можно подкорректировать и сделать правильно. GettingReal — это возможность изменяться на лету.



21. Разделяйте и объединяйте

Разбейте проект на десяток небольших кусков, если он требует10 недель работы. Если вы не можете держать большуюпроблему в голове, — разбейте её на такие части, которыелегко в вашей голове поместятся.

А вот организационно лучше объединять. Разделение поотделам и специализациям даёт то, что каждый специалиствидит только свой аспект приложения и не видит общейкартины. Как можно больше смешивайте команду, чтобыналадить диалог. Убедитесь, что разработчики знают, какработает поддержка; что поддержка знает, как дизайнерыпринимают решения; что дизайнер знает, как работаетфреймворк, на котором пишут программисты.

22. Единое время и никаких встреч

У вас должно быть единое время на работу. Особенно этоактуально в распределённой по часовым поясам команде.Установите время, в которое вы будете работать, ни на что неотвлекаясь. Сделайте половину рабочего дня временем, когдавы не будете отвечать на телефонные звонки, попусту



говорить с коллегами, чтение почты и т.д. Избегайте любыхперерывов в это время. Каждый перерыв отвлекает настолько,что потом необходимо опять вникать в работу.

Если вам понадобилась встеча, значит есть какая-тонеясность. Раз есть неясность, — значит у вас нет чёткогопонимания задачи. Это вытекает из нечётких целей, нечёткойпостановки или «трудностей перевода». Встречи разбиваютваш рабочий день на куски и выбивают из технологическогопроцесса.

23. Персонал. Нанимайте меньше и позже

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

Если у вас есть возможность быстро нанять много оченьхороших людей, — это тоже плохая идея: вы не сможетебыстро сделать из них хороший сплочённый коллектив. Будетмного головной боли, а на ранних этапах развития этосмертельно. Если вы с чем-то не справляетесь, подумайте, нужно ли этоделать вообще? Есть ли обходные пути? Только ели другоговыхода нет, — нанимайте.



[Примечание:] интересно, что это высказываниепротиворечит прочитанной мной ранее книге Good to Great,где говорится о том, что сначала наймите самых классныхлюдей, а потом уже решите, что вы будете вместе делать.

Помните, что персонал нужно проверять. Назначьтепотенциальным работникам испытательный срок. Назначайтетестовое задание: в процессе будет понятно, как человек ведётпроект, как общается, как работает и т.д. Не закрывайте глазана потенциальные проблемы; помните, что это проверочныйзабег.

Ищите потенциальных сотрудников среди Open Sourceразработчиков. Так вы проследите, что делал этот человекдлительное время и будет понятно, на что он способен. Выоцените человека по сделанному, а не по сказанному.Посмотрите на его видение, которое можно определить покомментариям и переписке в проекте. Его видение не должнопротиворечить вашему.

Ещё ваш сотрудник должен обладать энтузиазмом, задаватьвопросы, быть мастером слова (хорошо писать), эрудирован.

24. Интерфейс до программирования

http://megamozg.ru/post/8450/



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

С другой стороны, интерфейс — это и есть ваш продукт.Конечным пользователям вы продаёте именно его. 37signalsначинают с интерфейса и он постоянно пересматривается.

25. Три состояния программы

Делайте дизайн для обычного, пустого и ошибочногосостояний программы. В большинстве случаев мы видимпродукт, когда он заполнен. У нас есть тестовые данные,скрипты, которые заполняют БД автоматически и всё такое.Но зарегистрировавшийся только что пользователь видитсовершенно иную картину. Для него ваш продукт — эточистый лист. Помогите ему, чтобы он разобрался быстро иусвоил, как работать, что добавить в первую очередь. Сделайтеподсказки, которые будут направлять пользователей.

PS: на этом первую часть я закончу. Впереди вторая частьобзора этой очень полезной книги, а пока, если у вас естькакой-то опыт применения вышеизложенного, — пишите



ниже. Если есть грабли, — тоже пишите, обычно это особенноинтересно.

Принципы getting real

Documents