Тема: Техническая задача VS бизнес-задача, имеем ли мы право оставаться в рамках первой?

1. Бизнес-задача
Как перестать програмировать и начать жить
решать бизнес-задачи.
Дмитрий Завалишин, dz@dz.ru
Digital Zone, http://dz.ru
среда, 20 марта 13 г.

2. Не может быть
Некоторые технологически успешные проекты
погибают.
Некоторые технологически ужасные, на лицо
ужасные и вообще ужасные (кто сказал "ЖЖ"?)
проекты живут и побеждают.
Несправедливо? Ещё бы...
среда, 20 марта 13 г.

3. Может!
Нельзя писать программу. Надо решать задачу.
Концепция (vision) - список бизнес-целей!
Метрика успеха!
Приоритеты! Быстрый старт!
Вовлечённость заказчика!
Специализация исполнителя!
среда, 20 марта 13 г.

4. Мы склонны
предполагать, что
Чёткая постановка задачи существует или
достижима
Задача имеет одинаковое решение для всех
пользователей
Пользователи склонны договориться о том, какое
решение им нужно
Известны все пользователи
Цели пользователей пригодны к осознанию хомо
сапиенсом
среда, 20 марта 13 г.

5. Мы не склонны
предполагать, что
Со стороны клиента сменится команда.
Гендир клиента женится на дочке программистки,
и тёща будет курировать ваш проект. Тёща любит
турбопаскаль.
Пользователь проекта - не молодой технический
специалист, а главбухша 65 лет.
Админ клиента не знает, что такое ftp.
IT-департамент не знает, где у них firewall.
среда, 20 марта 13 г.

6. Не надо предполагать
Планируйте с учётом рисков. Хотя бы список!
Прописывайте в договоре риски и ответственность
заказчика за те из них, которые находятся в его
руках.
Не доверяйте аналитику (и даже выбор
стейкхолдеров) заказчику.
Ограничивайте фантазию на первом этапе проекта,
до ввода его в эксплуатацию.
среда, 20 марта 13 г.

7. Приоритеты
Сделайте всё, потом всё, что я ещё не придумал,
потом всё, что потребуется по месту, и потом всё,
что есть у конкурентов.
И у Микрософта. И Гугля с Фейсбуком.
Примените все современные достижения
науки - вы же профессионалы!
Мы не знаем, кто наш клиент, но юзабилити
должно быть на высоте.
Сколько???? Вы с ума сошли.
среда, 20 марта 13 г.

8. Приоритеты
Выделите три уровня приоритетов: критичный,
важный, желательный.
Критичный: без него вообще не едет.
Важный: без него - мучительно едет.
Желательный: розочки и бантики.
И критичных сценариев должно быть 30%, а не 90!
среда, 20 марта 13 г.

9. Заказчик должен думать
А теперь расскажи мне подробно, как ты сделаешь
на этом деньги!
Прошёл год, проект работает. Как ты измеришь его
успешность? Какой линейкой? Каков целевой
показатель?
Всё это отразить в концепции и требованиях!
Принимать все решения с оглядкой на бизнес-
цель!
среда, 20 марта 13 г.

10. Кто получит пользу?
Если внутри заказчика у проекта нет драйвера -
проект мёртв.
Гендир заказчика - не драйвер.
Если драйвер уволился - проект мёртв.
Идеальный драйвер - менеджер с надеждой на
повышение или партнёрство.
среда, 20 марта 13 г.

11. Нет драйвера?
Найдите!
Нет? Нарежьте проект на кратчайшие этапы!
Нет? Откажитесь.
Очень нужно? Найдите себе консалтера, сделайте
его генподрядчиком и отдайте ему 50% денег и
80% рисков.
Не жадничайте, делайте то, что умеете, не свою
работу отдавайте партнёрам. Но - проверенным.
среда, 20 марта 13 г.

12. Масштабы бедствия
Занижение бюджета проекта - риск. Завышение -
тоже. Надо попасть с первого выстрела.
Большинство проектов могут быть сделаны в
рамках десятикратного диапазона бюджетов.
Выбор варианта зависит от массы параметров.
Ваша цена сильно ниже? Вы что-то не заметили?
Пять девяток? Полмиллиарда хитов в час? Тёщу
гендира заказчика?
В договоре должны быть разделы "что мы делаем"
и "что мы не делаем".
среда, 20 марта 13 г.

13. План проекта - что
забыто?
Развёртывание среды (час? точно?)
Обучение (реально все всё знают?)
Общение с заказчиком (телепаты могут
пропустить), корректировки планов и др. документов
Слияние кода (Вася! Это был старый хедер!)
Деплой на тестовый сервер (и три дня
войны с админом заказчика за vpn)
Документацию. Шутка.
среда, 20 марта 13 г.

14. Что совсем не
планировали
После первого показа проекта выкинуть 50% кода
и начать заново, потому что они, наконец, поняли,
чего хотят. Или думают, что поняли.
Месяц интегрироваться с одной сторонней
системой, из которой вы зовёте одну функцию. Или
два месяца. Если система, с которой вы
интегрируетесь, стоит более полумиллиона
долларов, то - полгода.
Тёщу гендира заказчика.
среда, 20 марта 13 г.

15. Что вы сделали зря
Запроектировали гибкую универсальную систему.
Всех случаев всё равно не закрыли. Потратили
кучу времени. Оно тормозит и индексы не
помогают. А главное - при переделке на 50% всё
это полетит в помойку и покроется слоем
костылей.
За негибкость вас убьют потом, а за тормоза -
сразу.
Отсутствие рюшечек вообще никто не заметит.
среда, 20 марта 13 г.

16. Что - совсем зря
Применили незнакомую технологию. Вызвали из
небытия незнакомые проблемы. Развлечения было
на два дня (вооо - смотри тут как всё клёво!), а
мороки будет на полгода.
Новые технологии можно пробовать применять на
второстепенных частях.
И только когда основная функциональность
системы уже ожила.
Да и то...
среда, 20 марта 13 г.

17. Люди гибче программ
Люди - гибче программ. Пока.
Два решения могут отличаться в 10 раз
по затратам, но быть неотличимы с точки
зрения пользователя.
"Интерфейс со сторонней системой" - что
это? SOAP? Нет. REST? Нет. Corba? Нет. ssh +
демон? Нет. Запись в чужую БД? Нет.
Формирование бинарного файла? XML-файла?
Нет. Это "Лена будет брать текст из вашего окошка
и копипастить его в окошко той системы". Правда.
среда, 20 марта 13 г.

18. Будьте проще
Неидеальная работающая система сильно лучше
идеальной, лежащей в помойке.
Реализуйте важное. Неважное оставьте Лене и
Экселю. Проведите тестовую эксплуатацию - там
где Эксель взвоет и потребует прибавки к
жалованью - доработайте.
среда, 20 марта 13 г.

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

20. Code knowledge reuse
Риски - от неизвестности.
Решайте знакомые задачи.
Специализируйтесь.
(Веб-разработка - это технология, а не
специализация.)
Консультируйте заказчика. Знайте про его задачу
больше, чем он.
среда, 20 марта 13 г.

21. Заказчик?
Что вы у меня покупаете?
Нет, не программирование. Вы сами можете
набрать кодеров на рынке, они вам что-то накодят.
Уверенность в завтрашнем дне. Адекватные
технические решения. Опыт работы с рисками.
Качество.
среда, 20 марта 13 г.

22. Вопросы и мнения
Дмитрий Завалишин
dz@dz.ru
Digital Zone
http://dz.ru
среда, 20 марта 13 г.