Как бы затраты (не только денежные, но и ресурсов) на такой биллинг не перевешали бы все преимущества.
И кстати, сложность есть в планировании загрузки — одно дело пользователей запланировать, другое дело использование сервиса спрогнозировать.
Я не скажу что защищаю стандартную модель, но во всем есть свои плюсы и минусы.
Или даже (мои извинения за третий коммент подряд) «создайте свой стартап». И весь его ЖЦ чтоб на сайте был. Начиная с его создания вместе с калькулятором, созданием бизнес-модели, включая поддержку сообщества, ну и его дальнейшей жизнью. Посещаемостью, развитием, и так далее. Вплоть до продажи или закрытия.
Давайте поддержим начинание.
Предлагаю идею — сайт поддержки стартапов рунета. Подобного не нагуглил, всё в основном рекламное. Помощь советами, обратной связью, привлечение пользователей, возможно участие сообщества в разработке (кому хочется).
С удовольствием бы использовал, ради интереса и профессионального уровня, но приходится пользоваться некоторыми (достаточно старыми) бесплатными инструментами разработки, которые не поддерживают. Например, Embedded Visual C++.
Ага, и даже на терминалах (сбора данных) пока, к сожалению. Бывают и stack overflow, и low memory. А по сети передавать с них данные — отдельная сказка.
С точки зрения финансового менеджмента, без разницы кто вкладывается и чем. Все инвестиции должны отбиваться, NPV применим и к фирме, не только кредиторы его считают. Стоимость твиттера в миллиард во времена до первых денег с него — это и есть тот самый NPV. Вполне вероятно, что ваш стартап имеет ненулевую стоимость (NPV), зависит от… наверное напишу статью…
Наверное не открою секрет, что такие проекты — инвестиционные. В них вкладываются, чтобы получить отдачу. И тут сроки важны по следующим причинам — конкуренция, опять же сроки — это деньги исполнителям, опять же сроки — это насколько исполнители будут заняты проектом А (а не другим важным Б или В), и наконец сроки — это сколько времени пройдет до начала положительных денежных потоков по проекту (время начала которых влияет на такой показатель как NPV).
А статью напишите, будет интересно почитать. Свои продукты — это всегда интересней чем заказ.
Ну у Заказчика на ПО свои задачи завязаны, это раз.
Пожалуй, самое главное, что в процессе разработки используется время программистов и других специалистов, которое нужно оплачивать. И это время денег стоит. Вот смотрите, программист за месяц может поучаствовать в 1,2,3… проектах (не только разработкой, но и поддержкой, и так далее). Как разносить затраты по проектам? По часам.
Оценки «по аналогии» (разработка такого продукта может стоить «столько-то») неточны. Нет базы для совершенствования разработки и управления проектами в компании. Неизвестно, окупится ли мероприятие, или нет. А когда есть детальная разбивка по задачам, заметно снижаются и риски. Известно, что суммарная ошибка оценки падает при детализации как корень из N.
ИМХО, ИТ уже не та отрасль, в которой сверхдоходы крутятся. Всё больше становится, гм, промышленной что ли. Поэтому и подход к выполнению заказов — проектный, а в проектном деле оценка снизу-вверх (сроков, затрат, рисков, качества и др.) давно уже оправдывает себя.
Если совсем кратко, то оценка сроков нужна чтобы не облажаться по деньгам.
Оценки нужны для составления бюджета проекта. Если заказчик готов оплачивать потраченные часы по факту — его дело, тогда есть еще о чем поспорить. Да и то, команду синхронизировать надо в рамках задач каждого, одна фича быстрее вырастет, чем другая например. Самое паршивое в проектах — это удивляться.
И более того. Если внимательно посмотреть на диаграмму Гантта (это там, где оценки), иногда можно ускорить проект раза так в два. Но agile диаграмма Гантта не нужна, я знаю.
Какое может быть сходство в разработке, если языки разные. А то что элементы называются похоже, ну так они на то и одинаковые, чтобы не называться по-разному.
А есть у вас что-то с управлением стоимостью проектов? Было бы здорово.
И кстати, сложность есть в планировании загрузки — одно дело пользователей запланировать, другое дело использование сервиса спрогнозировать.
Я не скажу что защищаю стандартную модель, но во всем есть свои плюсы и минусы.
Предлагаю идею — сайт поддержки стартапов рунета. Подобного не нагуглил, всё в основном рекламное. Помощь советами, обратной связью, привлечение пользователей, возможно участие сообщества в разработке (кому хочется).
А статью напишите, будет интересно почитать. Свои продукты — это всегда интересней чем заказ.
Пожалуй, самое главное, что в процессе разработки используется время программистов и других специалистов, которое нужно оплачивать. И это время денег стоит. Вот смотрите, программист за месяц может поучаствовать в 1,2,3… проектах (не только разработкой, но и поддержкой, и так далее). Как разносить затраты по проектам? По часам.
Оценки «по аналогии» (разработка такого продукта может стоить «столько-то») неточны. Нет базы для совершенствования разработки и управления проектами в компании. Неизвестно, окупится ли мероприятие, или нет. А когда есть детальная разбивка по задачам, заметно снижаются и риски. Известно, что суммарная ошибка оценки падает при детализации как корень из N.
ИМХО, ИТ уже не та отрасль, в которой сверхдоходы крутятся. Всё больше становится, гм, промышленной что ли. Поэтому и подход к выполнению заказов — проектный, а в проектном деле оценка снизу-вверх (сроков, затрат, рисков, качества и др.) давно уже оправдывает себя.
Если совсем кратко, то оценка сроков нужна чтобы не облажаться по деньгам.
P.S. А тэг канбан к чему тут?
И более того. Если внимательно посмотреть на диаграмму Гантта (это там, где оценки), иногда можно ускорить проект раза так в два. Но agile диаграмма Гантта не нужна, я знаю.