apavlyut (deppkind) wrote,
apavlyut
deppkind

Как сделать сайт (Блог / CRM / Магазин / Соцсеть / Лэндинг ...) и не сесть в лужу.

Быстрый ответ - вот простая последовательность:

  1. Определить что хотим.

  2. Сформулировать требования к целевой системе.

  3. Выбрать путь решения - готовый сервис / внедрение решения / собственная разработка.

  4. Внедрить.

Определяемся

Обязательно пишем назначение - какую пользу, кому и как будет приносить эксплуатация нашей системы.

Составляем простой список действующих лиц, заинтересованных (работающих напрямую) с системой, и влияющих на ее появление - это все персонажи, с которыми будет идти коммуникация на всем жизненном цикле от задумки до запуска.

Директор, менеджер, бухгалтер, smm спец - все кто задействован в назначении системы.

Составляем список хотелок от системы простым списком.

Выявляем требования

Требования это прослойка между реальным бизнес-процессом (не хотелкой) в компании и возможностями в архитектуре целевой системы.

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

Требования конкретные к системе всегда нужны, потому как всегда возможны два варианта:

  1. Если ты не знаешь что ты хочешь, то любая система тебя удовлетворит.

  2. Если ты не знаешь что ты хочешь, то никакая система тебя не удовлетворит.

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

А типичный грешок самих разработчиков систем (и меня ранее конечно-же, кто не грешен) - это попытка быстренько порешать за клиента как он видит работу с системой по своим хотелкам - и пытаться сделать систему и попасть в пункт номер 1, а по факту всегда попадает в пункт номер 2.

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

Поэтому требования нужны всем, и это важный кусок предпроектных работ.

Нельзя написать требования не зная бизнес-процессов в формате выходов и входов из них - а как я не раз писал, 90% малого и среднего бизнеса ничего не пишут, а хранят и накапливаю все процессы в своих киборгах (сотрудник + его комп);

Хотелки используются как входные точки в диалоге при поиске и выявлении реальных требований к системе. Я рекомендую применять метод JobStories (http://deppkind.livejournal.com/3259.html) который просто бомбит инсайтами (http://deppkind.livejournal.com/4344.html) на полную катушку.

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

Сами требования клиент не выявит, а разработчикам никогда не известны и просто так они их не напишут если им сказать любимое клиентское "ну там вот посчитай так и так" - требования составляются на основании бизнес-хотелок выявленных из встреч с заинтересованными лицами клиента.

Почему требования "выявляются" и никогда не известны полностью:


  1. Бизнес-процесс не описан (не известен).

  2. Бизнес-процесс описан но в процессе формулировки требования и атаки инсайтами - бизнес-процесс сам по себе улучшился или определился в конечный вид.

Выявленные требования согласовываются, подтверждается (доказательством артефакта) получаемая польза, согласуются друг с дружкой (не противоречивость) - фиксируются, подписываются и замораживаются.

Кому нужны примеры табличек хотелок+выявленных требований или просто шаблоны - велком, скоро будет на сайте.

Если кратко подсказать то требования описывают любую систему как "черный ящик" - мы понятия не имеем что там внутри и как она работает, но знаем что если мы тыкнем в нее пальцем, она нам подмигнет. Ни слова про то как она это делает, зато понятно что она делает и с кем.

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

Выбираем пути решений

Сравнивается предложение существующего рынка - нужно составить список целевых систем которые предлагает рынок.

Нужно четко имеет ввиду что большинство популярных проблем бизнеса уже давно решены, и внедряются за 5$ / мес. Поставка через сервис существенно экономит бюджет, давая качество хорошей системы, разработку которой можно не поднять и за пол года, с хорошей командой разработчиков - вот и тут начинается сравнение.

Разработка собственного решения, а не внедрения существующего обоснована и возможна только после ответов на вопросы:

  1. Существующие решения точно не перекрывают составленные требования - об этом свидетельствует сравнительная таблица существующих функций систем против ваших требований.

  2. Требования точно не перекрываются, и изменение хотелок под одно из существующих подходящих хотя-бы уже на 50-70% решений (подвинуться в хотелках и выбрать то что есть) существенно снижает получаемую итоговую пользу от внедрения в таком усеченном формате требований.

  3. Решение согласуется с требованиями, формат его поставки SAAS - риск отказа системы в эксплуатации по различным причинам (сеть, банкротство, атаки, сбои, прочее) - принесет существенные повреждения бизнесу, остановит деятельность или создаст угрозу его прекращения ввиду финансовых и прочих появившихся проблем.

  4. Решение согласуется с требованиями, поставка решения идет путем внедрения - стоимость "внедрения" в работу компании выше стоимости создания собственного решения на заказ или своими силами.

Если с требованиями справились и ответили хотя бы на один пункт ответ - да, значит вам нужна собственная разработка.

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

Но если деятельность находится на начальном этапе старта / роста - ввиду экономии ресурсов и быстрого получения результата я всегда настоятельно рекомендую пробовать пользоваться готовым решением и сосредоточится на своей деятельности:

У меня в студии этот тариф называется "Жигули" http://www.deppkind.com/devprocess#soluton, аналогия в названии выбрана не случайна и не является приколом, это простым языком сказанные вещи понятные всем - из точки А в точку Б вы доберетесь и на жигулях и на БМВ.

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

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

P.S Про то что должно быть на лендинге, что должна делать crm система и в целом про примеры требования в следующих сериях.


Всем систем и осознанности,
всегда ваш - Саша Павлють.
Tags: crm, инсайт, информационные системы, лендинг, мобильные приложения, сайт, требования
Subscribe

Recent Posts from This Journal

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments