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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Страсть

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

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

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

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

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

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

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

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. Вариантов выбора настроек нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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