Как быстро делать «быстрые» проекты

Начнем с того, что сегодня требуется делать проекты быстро и быстро их запускать

Но многие считают, что быстро сделать и получить финал — это одно и тоже

В итоге проекты умирают только из того, что они были СРОЧНО нужны. Хотя на самом деле люди жили без них несколько тысяч лет.

План:

  1. не спешить
  2. определить график выпуска бет
  3. весь свой маркетинг бросить на промоушн и сбор фидбеков от бета версии
  4. получив результаты, работать дальше

Сегодня сделать бета версию дешевле чем несколько лет назад

поэтому это нужно пользоваться

Если заказчик хочет срочно продукт, то необходимо изменить подход к разработке

Заказчики хотят очень быстро получить проект, настолько быстро, что иногда они забывают о том, что как-то человечество жило без этого ПО

В итоге они начинают загонять группу разработки и требуют от них финальный продукт, а не прототип или бета версию

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

В принципе и разработчики не всегда берутся за МЕГА СРОЧНЫЙ проект только потому что заказчик не говорит что прототип будет — ОК

Или говорит — ЭТО ДОЛЖЕН БЫТЬ ФИНАЛЬНЫЙ ФИНАЛ

Заказчики у которых проект говорит, делятся на 3 группы

  1. Есть проекты которые около ИТишные. Например, банк запускает новую банковскую карту и нужен промо сайт. Понятно, что сайт не главное в этом деле и про него вспомнили в самом конце.В принципе, в этом случае проект или простой и не такой мега супер важный — как считает заказчик
  2. Второй случай когда ПРОЕКТ СРОЧНЫЙ — больше относится к большим корпорациям или гос. организациям. На создание какого-то проекта в начале года выделяется бюджет, который обязательно нужно потратить именно в том году, когда его выделили
  3. Этот случай встречается чаще — заказчик полный уебан.

Не должны выходить без беты системы где:

  1. планируется очень много пользователей
  2. меняют привычный workflow. Например, в ворде решили убрать кнопку Save — теперь документы сами сохраняются, когда пользователь убирает руку с клавиатуры. Или раньше все подавали декларации в бумажном виде, а теперь будут в электронном
  3. работают по очень хитрому алгоритму

Например, 90% програм для управления проектами пишут люди которые никогда в жизни не управляли серьезным проектом

в принципе

Поэтому нужно менять подход к процессу разработки

В самом начале нужно планировать бета версию — because it’s more than nothing

И проверять как это будут все воспринимать

Только после этого стоит говорить о срочности

Другой пример — компания хз почему каждый год к 1 апреля выпускает новый проект

За 2 недели до первого числа они размещают баннеры на всех своих ресурсах, что мол мы впервые 1 апреля сделаем кое что действительно крутое

Никто не знает что происходит за баннерами…. а там бегает менеджер и заставляет разработчиков ебошить по ночам эти ёбаные мега проекты

В итоге 1 апреля, все любопытные интернетчики жмут на F5 чтобы посмотреть новый проект, а его нет, потому что еще не успели…

Во второй половине дня он появляется, когда уже никого нет, и потом 2-3 недели этот проект тестируется и не работает

К чему такая срочность? Спросите у любого прохожего на улице, когда был запущен instagram?

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

А сегодня что?

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.