Getting Real (на русском) - [4]

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

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

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

Два пути

Джейк Уолкер создал одну компанию при помощи инвестора (Disclive) и другую — без его помощи (The Show). Он делится различиями между этими путями:

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

С The Show мы поняли, что можем создать намного лучший продукт с меньшими затратами. Только на это понадобится больше времени. Мы рисковали небольшим количеством собственных денег и ожидали, что люди на энтузиазме будут стремиться к качеству и скорости работы. И компания осталась (и, вероятно, продолжит быть) с небольшим оборотом. Начиная с первого проекта мы полностью были на самообеспечении. Из-за маленьких сроков работы с клиентами у нас вообще не было необходимости вкладывать действительно немаленькие средства в бизнес. И мы хотели не вырастить бизнес и продать его, а развивать его и продолжать извлекать из этого прибыль.

— Комментарий на блоге Signals vs. Noise.

Фиксируйте время и бюджет, делайте возможности гибче

Запускайте вовремя и согласно смете

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

Бытует миф: мы можем начать вовремя, уложившись в бюджет и реализуя всё предполагаемое. Это практически никогда не выходит, но когда так происходит, от этого страдает качество.

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

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

Вот выгоды гибких возможностей и фиксированных времени и бюджета.

Расставление приоритетов

Выясните, что действительно важно. Что сподвигло на создание продукта? Это вызовет ограничения, которые сподвигнут вас на принятие быстрого, точного и жёсткого решения вместо тупого «мямления».

Действительность

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

Гибкость

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

Рекомендуем сократить возможности. Лучше сделать половину продукта, но качественно, чем недоделку.

Раз, два, три...

Возможно ли выполнить проект за год до намеченной даты? Когда-нибудь, наверное.

—Фред Брукс, инженер ПО и программист.

Заведите себе врага

Боритесь

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

Когда мы решили создать систему управления проектами, мы знали, что MS Project был гориллой в комнате. Боясь горилл, мы использовали это для мотивации. Мы решили, что Basecamp будет ему полной противоположностью, анти-Project.

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

Нашими врагами были Диктаторы Управления Проектами, которые имели обыкновение «бить кнутом». Мы хотели демократизировать управление проектом, сделать так, чтобы каждый был его частью (включая клиента). Проекты становятся лучше, когда у каждого есть интересы в нём.

Когда начали работу над Writeboard, мы знали, что есть конкуренты этому продукту с гораздо большим количеством возможностей. Таким образом мы решили выделить «простоту» вместо этого. Мы создали приложение, которое позволило людям легко делиться идеями и сотрудничать, без увязания в несущественных особенностях. Если что-то было несущественным, мы отказывались от этого. А через три месяца после запуска было создано более чем 100 тыс. Writeboard-ов.

Когда мы начали работу над Backpack, нашими врагами были структура и твёрдые правила. Люди должны организовывать информацию как им удобно, не основываясь на всеобщих убеждениях «как надо».