Ежемесячные архивы: July 2016

Как, когда и зачем закрыть проект?

Момент который недооценивают, а часто вобще игнорируют при проектировании чего-либо – момент закрытия проекта. Очень мало кто умеет грамотно закрываться. А между тем – это важный этап, возможно – самый важный.

Очевидный вариант – просто все бросить. И программисты чаще всего поступают именно так. Но давайте рассмотрим аналогию – обычный, не ИТ сервис, допустим, ксерокопирование. Разве человек, оказывавший в прошлом копировальные услуги станет выбрасывать копир, только потому, что он более не намерен оказывать такую услугу? Нет, он его продаст. На вырученные деньги он может купить другое оборудование, например – мотокультиватор и далее оказывать услугу по вспашке земли на дачных учасках. Если же он просто выбросит копир – то на мотокультиватор может уже не хватить.

Основная цель грамотного закрытия – обеспечение возможности горизонтального скачка в экономическом пространстве.

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

Подход номер 1, продажа
Если мы не выходим на ИПО, то мы должны максимально приблизится к этому состоянию. Подготовить проект к продаже. Реорганизовать его таким образом, чтоб новый владелец мог продолжить работу над проектом не обращаясь к предыдущему владельцу. Четко сформулировать, что именно продается. Написать инструкции, описать бизнес-процессы, ключевые показатели эффективности, методы анализа работы проекта. Упаковать в красивое, понятное, разумное коммерческое предложение.

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

Подход номер 2, декомпозиция
Если мы не можем подготовить проект к продаже в стиле IPO, мы можем разобрать его на куски. В певую очередь следует выделить самые проработанные элементы и вытащить их в отдельные проекты. Далее их можно продать, используя подход номер 1, или использовать их для создания нового проекта.

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

Подход номер 3, отдам даром, самовывоз
Это как избавиться от старого холодильника, который вам лень спускать с 9ого этажа. Если рыночная стоимость вашего проекта меньше нуля (а если его никто не покупает, то она точно не больше нуля), то подарив проект вы получаете выгоду. Возможно, его кто-нибудь в итоге допилит и вы сможете воспользоваться плодами своих трудов уже как пользователь.

Этапы работы над Open-source проектом

  1. Определение потребности
    “Мне нужно это, нужно ли это кому-то еще?”
    Время – не более 1 дня, в идеале – час.
  2. Анализ возможностей
    “Я могу это сделать сам или могу нанять вот этих конкретных людей”
    Время – 1 час.
  3. Определение бюджета
    “На проект я могу потрать не более стольки-то рублей и(или) стольки-то рабочих часов”
    1 час.
  4. Постановка задачи
    “В рамках этого бюджета, для удовлетворения выбранной потребности я могу позволить себе вот такое решение”
    1-8 часов.
  5. Ревью постановки задачи
    “Могу ли я упростить задачу или иначе сократить расходы? Если да, то я изменю постановку задачи”
    1 час.
  6. Непосредственно программирование.
    “Если проект решает мою потребность, то результатом этого этапа должно стать удовлетворение моей потребности”
    Время – не более отведенного в рамках бюджета.
  7. Альфа – тестирование
    “Итак, попробуем воспользоваться результатами”
  8. Архивация текущей версии
    “Нужно сохранить код в надежном месте, не подверженном влиянию третьих лиц. Например, на собственном сервере.”
  9. Публикация
    “Чтобы максимизировать отдачу, нужно опубликовать везде где только можно, source forge, github, freshmeat, собственный сайт и так далее. Глупо использовать только один сервис.”
  10. Выстраиваем обратную связь
    “Проще всего – увязать сервисы для публикации с email. Можно указать email для связи с разработчиком в readme. Можно поднять собственный багтрекер. Можно всех заворачивать на один специально выбраный сервис публикации. Единственый вариант который может принести мне доход – это общение через собственный ресурс. Если у меня есть возможность общатся через собственный ресурс – я буду использовать именно этот вариант. Если нет – я буду использовать вариант удобный мне лично, игнорируя популярность инструмента у пользователей, поскольку определяющим фактором является снижение расходов на поддержку пользователей”
  11. Обрабатываем сообщения пользователей, выстраиваем приоритеты:
    “Если это устранив проблему выявленную пользователем я сразу зарабатываю на этом деньги – это высший приоритет, если не зарабатываю, но это дает мне возможность заработать в будущем – это обычный приоритет, если устранение проблемы никак не влияет на мой заработок – это низкий приоритет, даже если этот баг приводит к краху всей системы у обратившегося. Устранение багов – это потраченое время, а время – деньги”
  12. Goto 3 (определяем бюджет следующей версии и далее по циклу)