Документ обсуждает внутренние процессы IT-бизнеса, акцентируя внимание на важности процессов для выпуска доступного продукта, а не на строгом следовании техническому заданию. Он также рассуждает о методах agile, таких как scrum и kanban, и о важности командной работы и регулярных обновлений продукта. В конце подчеркивается, что успех стартапа зависит от правильного подбора процессов и инструментов, а также от понимания потребностей клиентов на стадии минимально жизнеспособного продукта (MVP).

1. Какие внутренние процессы у IT
бизнеса?
Что важнее - люди или процессы? Сделать
вовремя или хорошо? Работать по ТЗ или Agile?
Антон Карпенко - серийный предприниматель
Программист, электронщик, изобретатель
Технический архитектор в нескольких стартапах
а так же CTO в Happy Farm Business Incubator
http://tnation.co

2. Продукт должен быть выпущен!
Процессы важнее людей, но все это не важно если
продукт недоступен пользователям, не работает как
ожидается или его невозможно купить.
В современном мире уже нет "коробочных продуктов",
все изменяется, улучшается, обновляется, чаще
всего автоматически.
Continuous D (delivery, deployment, development) - это
стандартные процессы современного IT бизнеса.
http://tnation.co

3. Вовремя или регулярно?
Если вы не успеваете запустить и отладить продукт до
рождественских распродаж - это плохо.
Но еще хуже если вы месяцами не будете развивать
продукт, добавлять требуемые пользователями фичи,
исправлять ошибки, следить за совместимостью!
Рекомендую выбрать регулярные релизы и апдейты,
с таким подходом любое важное событие тяжело
пропустить. :)
http://tnation.co

4. Техническое задание
Техническое задание (ТЗ) - основа любых инженерных
решений. К сожалению, у IT бизнеса мало общего со
строительством моста или запуском спутника.
Скорее всего ТЗ придется выбросить в мусорный бак,
в тот самый куда уже улетел бизнес план. :)
Но если хоть какая-то часть бизнес логики может быть
описана четким техническим заданием - радуйтесь!
Сделать часть продукта по ТЗ можно чужими руками,
через аутсорс или с привлечением фрилансеров.
http://tnation.co

5. Совместная работа и приоритеты
Даже если у вас в команде гуру-программист, он не
сможет постоянно успевать делать все сам. Готовьтесь
к командной работе с самого начала. Пусть кодер сам
ставит себе задачи, сортирует их по приоритету в паре
с руководством, и только потом выполняет.
Закрытие нужного таска - для бизнеса важнее самого
кода, результата тестов и даже потраченного времени!
Version control для кода (Git, SVN, Mercurial), а так же
регулярные backup для важных данных надо вводить
как можно раньше.
http://tnation.co

6. Что такое Agile и с чем его едят?
Agile методами называют все подряд. На самом деле
это набор Lean методик (устранение потерь, задержек)
соответствующий Agile Manifesto:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Отлично подходят когда результат нужен быстро,
задачи не определены или условия могут меняться
быстрее, чем заканчивается процесс разработки.
http://tnation.co

7. Что в Agile хорошо и что плохо
Kanban - не требует изменения существующих методик
и может быть добавлен на любой стадии "бардака".
Это не "серебряная пуля", но многое станет понятно.
Scrum - циклический процесс, каждая итерация дает
новую версию рабочего продукта. Хорош на стадиях
активной разработки уже запущенного продукта.
Требует изменений в руководстве команды и проекта.
Feature-driven development - хорошо подходит для
продуктов с большим количеством функций и подзадач.
Test-driven development - в теории отлично, на практике
подходит только для 2й-3й версии готового продукта.
Extreme Programming (XP) - не трогайте это! :)
http://tnation.co

8. Разработка это далеко не всё!
Бизнес это все-таки не о программировании, а о
заработке на удовлетворении потребностей клиентов!
Хотите сконцентрироваться на главных задачах
бизнеса, без технических проблем и срыва сроков?
Внедрите отлично настроенный циклический процесс
разработки (scrum или подобное), автоматическое
тестирование, deployment в один клик, раздельные
backlog для features и bugs, другие технологические
"плюшки". Это совсем несложно, зато очень полезно!
http://tnation.co

9. Где разработка в Startup?
Краткая биография среднестатистического стартапа:
● Поиск и определение проблемы.
● Формирование команды и изготовление
прототипа.
● Стадия Minimum Viable Product (MVP).
● Первые пользователи продукта, денежный поток,
подтверждение бизнес концепции.
● Break-even point и растущие обороты и доходы.
● Масштабирование бизнеса и захват рынка.
● Поглощение или IPO.
http://tnation.co

10. Startup в стадии MVP это долго!
MVP это не фиксированное состояние, а процесс!
Это не бета-версия и не релиз-кандидит. Это стадия
прототипа продукта или сервиса, с ограниченным
набором функций. Любой потенциальный клиент,
попробовав частичный прототип, сможет принять
решение нужен ли ему подобный продукт в будущем.
Самое главное на стадии MVP нащупать то, за что:
Клиент платит деньги!
http://tnation.co

11. Процессы и инструменты в Startup
http://tnation.co
Стадия Процессы, методы и инструменты
Проблематика Блокнот, Google Drive, Dropbox и т. д.
Изготовление
прототипа
Карточки в Trello. BitBucket, GitHub или
свой Git server для контроля версий.
MVP
эксперименты
Kanban или "легкий Scrum". Аналитика с
результатами и расчетами в Google Docs.
Живой
продукт
Scrum или подобный циклический процесс.
Автоматические тесты и Deploy. Скорее
всего Jira у девелоперов.

12. Спасибо за внимание :)
Я Антон Карпенко, но все зовут меня KARPOLAN
karpolan@karpolan.com
+38 (093) 394-48-15
http://karpolan.com
Гуглюсь по KARPOLAN или "Темечковый Дятел"
Обращайтесь, отвечу на любые вопросы :)
http://tnation.co