300 Startups Forum - Typical Mistakes in IT Business (Rus)
1. Типичные ошибки при
создании IT проектов
Сам совершал, встречал у других и
увижу еще не раз :)
KARPOLAN.COM
Антон Карпенко - серийный предприниматель
Программист, электронщик, изобретатель
Технический архитектор в нескольких стартапах
и все еще CTO в Happy Farm Business Incubator
2. Зачем вообще что-то делать?
Ответьте себе, только честно:
● Разве нет готового решения?
● Почему Exсel, Photoshop не подходят?
● А точно именно это надо клиенту?
● Спрос и клиенты есть вообще?
● Клиент точно платит за разработку?
Может все-таки передумаем делать что-то
свое и будем перепродавать готовое?
KARPOLAN.COM
3. Совершаем первую ошибку!
Решаем изготовить собственный Software
или Hardware продукт, так "дешевле" :)
Абсолютно забываем что разработка это
только маленькая часть бизнес-процессов.
Производство и эксплуатация - вот куда
уйдет 90% времени и сил! Для физических
товаров еще добавятся склады, доставка,
утери, возвраты, ремонт и многое другое...
KARPOLAN.COM
4. Разработка или эксплуатация?
Что у бизнеса вокруг вашего продукта
займет больше времени и рабочих рук?
Выбирайте технологии и процессы исходя
из бизнес-задач, а не под программистов!
Берите готовые библиотеки, скрипты, CMS
за основу - не изобретайте велосипеды.
Сделать грабли не сложно, а вот поддержка
и обновления создадут геморрой!
KARPOLAN.COM
5. Техническое задание
Техническое задание (ТЗ) - основа любых
инженерных решений. Но у IT бизнеса мало
общего со строительством или авиацией.
Скорее всего ТЗ придется выбросить в тот
самый мусорный бак куда уже улетели
изначальные бизнес-планы :)
Получше дела с этим у hardware проектов,
там ТЗ и спецификации необходимы!
KARPOLAN.COM
6. Совместная работа и приоритеты
Внедрите version control для кода (Git, SVN, Mercurial),
а так же регулярные backup для важных данных. Иначе
бег по граблям будет проходить регулярно и по кругу :)
Даже если у вас в команде гуру-программист, он не
сможет постоянно успевать делать все сам. Готовьтесь
к командной работе с самого начала. Пусть прогер
сам ставит себе задачи, сортирует их по приоритету в
паре с руководством, и только потом выполняет.
Закрытие определенного таска в нужное время - для
бизнеса важнее самого кода, результата тестов и даже
потраченного времени!
KARPOLAN.COM
7. Вовремя или регулярно?
Если вы не успеваете запустить и отладить продукт до
рождественских распродаж - это плохо.
Но еще хуже если вы месяцами не будете развивать
продукт, добавлять требуемые пользователями фичи,
исправлять ошибки, следить за совместимостью!
Рекомендую выбрать регулярные релизы и апдейты,
с таким подходом любое важное событие тяжело
пропустить. :)
У hardware все так же, партия товара называется.
KARPOLAN.COM
8. Agile и хорошо, и плохо
Agile методами называют все подряд. На самом деле
это набор Lean методик (устранение потерь, задержек)
соответствующий Agile Manifesto.
Подходят когда результат нужен быстро, задачи не
определены или условия могут меняться быстрее, чем
заканчивается процесс разработки. Годится для
регулярно повторяемых задач, например deployment.
Не подходят для разработки важных архитектурных
решений. Так же не стоит тащить agile в hardware и
"коробочные" продукты...
KARPOLAN.COM
10. Какие будут рекомендации?
Помните что бизнес это не об инженерии, а
о заработке на удовлетворении клиентов!
Внедрите настроенный циклический
процесс разработки (scrum или подобное),
автоматическое тестирование, deployment в
один клик, раздельные backlog для features
и bugs, другие "стандартные" процессы.
Это совсем несложно, зато очень полезно!
KARPOLAN.COM