Комментарии 21
Слишком категорично. Автор оригинального текста — технарь-перфекционист, далекий от бизнеса. Если используемые технологии не будет пересматриваться, то быстрее и проще итерациями продолжить развивать существующий прототип (переписывая некорректные части) чем начинать всё с нуля, желая достичь совершенства. Идеально не получиться — некоторые части всё равно придется переписать много раз и тут важно быстрее увидеть проблемы о которых в начале пути мы может даже не подозревать. Нет никакого смысла буксовать на старте.
Выпуститься быстро, а потом фиксить баги чаще всего важнее чем выпуститься без ошибок, но слишком поздно (если это конечно не софт по управлению ядерными ракетами).
Выпуститься быстро, а потом фиксить баги чаще всего важнее чем выпуститься без ошибок, но слишком поздно (если это конечно не софт по управлению ядерными ракетами).
Есть разница между POC и просто использованием новой технологии.
В большинстве случаев, разница между двумя технологиями не видна, потому что в ПО используется куча всего, и выделить один конкретный момент — проблематично.
Поэтому POC — это штука, которая разрабатывается именно для DEV или DEMO, и действительно не должна быть связана с реальным продуктом, потому что в POC можно на ходу что-то править, ковырять, отбрасывать и это не должно никого аффектить. Полная свобода действий, чтобы узнать разные возможности новой технологии.
А уже потом думать и нести в основной проект то, что подходит, и возможно еще и адаптировать уже под существующую архитектуру.
В большинстве случаев, разница между двумя технологиями не видна, потому что в ПО используется куча всего, и выделить один конкретный момент — проблематично.
Поэтому POC — это штука, которая разрабатывается именно для DEV или DEMO, и действительно не должна быть связана с реальным продуктом, потому что в POC можно на ходу что-то править, ковырять, отбрасывать и это не должно никого аффектить. Полная свобода действий, чтобы узнать разные возможности новой технологии.
А уже потом думать и нести в основной проект то, что подходит, и возможно еще и адаптировать уже под существующую архитектуру.
У меня часто складывается такое впечатление, что вот такие вот статьи пишутся человеком, который настолько же далек от бизнеса, насколько далек и от разработки.
В жизни и бизнесе особенно нет никаких догматов, не рушимых правил и самое главное — перфекционизма. Ибо если за ними гнаться — ты будешь всегда вне бизнеса.
Т.е. все это может быть хорошо для тебя или твоего пет-проекта, но ужасно именно для бизнеса.
В бизнесе важна скорость и наверное это самый главный показатель. Бизнесу все равно, что под капотом, как красив код и на каких костылях там все это крутится. Так вот — если ты успел выкатить хотя-бы POC, пока твои конкуренты что-то там шлифуют в кулуарах — ты уже в тренде. Набивший уже оскомину Маск вам пример.
А в разработке всегда проще шлифовать хоть что-то, пусть даже POC, чем ничего.
И, зачастую, кроме POC изначально ничего и нет т.к. см. верхний тезис про бизнес.
Кроме того, POC позволяет оценить в том числе и нагрузку, да и вообще хоть что-то на проде.
Может он вообще не нужен? И разрабатывать далее это не надо.
Это гораздо дешевле и быстрее, чем точить ненужную фичу полгода и потом, выкатив ее, убедиться что все полимеры ушли зря…
В жизни и бизнесе особенно нет никаких догматов, не рушимых правил и самое главное — перфекционизма. Ибо если за ними гнаться — ты будешь всегда вне бизнеса.
Т.е. все это может быть хорошо для тебя или твоего пет-проекта, но ужасно именно для бизнеса.
В бизнесе важна скорость и наверное это самый главный показатель. Бизнесу все равно, что под капотом, как красив код и на каких костылях там все это крутится. Так вот — если ты успел выкатить хотя-бы POC, пока твои конкуренты что-то там шлифуют в кулуарах — ты уже в тренде. Набивший уже оскомину Маск вам пример.
А в разработке всегда проще шлифовать хоть что-то, пусть даже POC, чем ничего.
И, зачастую, кроме POC изначально ничего и нет т.к. см. верхний тезис про бизнес.
Кроме того, POC позволяет оценить в том числе и нагрузку, да и вообще хоть что-то на проде.
Может он вообще не нужен? И разрабатывать далее это не надо.
Это гораздо дешевле и быстрее, чем точить ненужную фичу полгода и потом, выкатив ее, убедиться что все полимеры ушли зря…
Никто же не говорит, что PoC'и не нужны.
Статья полезная. В моем опыте было такое, что после перевода PoC'a в статус полноценного продукта «быстрые» решения из него перекочевывали в конечный продукт, и их приходилось выкорчевывать годами, убеждая команду, что они не подходят для нормального, поддерживаемого годами продукта.
Как у UI-разработчика, был такой опыт, что для PoC'a например берут фреймворк для прототайпинга типа Bootstrap, но после одобрения PoC'a и создания конечных дизайнов (не основанных на дизайн-языке BS) Bootstrap остается в коде, хотя в нем уже нет необходимости.
Статья полезная. В моем опыте было такое, что после перевода PoC'a в статус полноценного продукта «быстрые» решения из него перекочевывали в конечный продукт, и их приходилось выкорчевывать годами, убеждая команду, что они не подходят для нормального, поддерживаемого годами продукта.
Как у UI-разработчика, был такой опыт, что для PoC'a например берут фреймворк для прототайпинга типа Bootstrap, но после одобрения PoC'a и создания конечных дизайнов (не основанных на дизайн-языке BS) Bootstrap остается в коде, хотя в нем уже нет необходимости.
Дак у вас проблема не в POC, а в том, как его развивали дальше, правда?
POC тут не причем.
Давайте пример — предположим вместо POC у вас было хорошо сделанное продакт-решение, но его принялись развивать не в том направлении или не на тех технологиях и т.д. — в конце будет точно такое-же, что вы описали.
POC тут не причем.
Давайте пример — предположим вместо POC у вас было хорошо сделанное продакт-решение, но его принялись развивать не в том направлении или не на тех технологиях и т.д. — в конце будет точно такое-же, что вы описали.
Набивший уже оскомину Маск вам пример.
С Маском как раз плохой пример. Он не выкатывал POC и даже Rodster и Model S были вполне сносными электромобилями, по крайней мере лучше всех, что были до и у многих — после.
Ну и POC в software и hardware — это две большие разницы, как говорится.
С Маском был пример про скорость в бизнесе и выкладывание сначала своих еще ничем не подкрепленных концепций или совершения аналогичных действий, рассчитанных лишь на то, чтобы застолбить нишу — это POC в чистом виде.
ничем не подкрепленных концепций
Можете привести пример?
POC в чистом виде — это его подземный туннель, который он сделал сам для себя. Никого не аффектил, ни с кем не договаривался, а просто построил и продемонстрировал как это может быть, обосновал и скорость разработки и стоимость строительства и даже на ходу поменял варианты с тележкой на рельсах на боковые колеса — если бы это был не POC такое изменение уже было бы не возможно.
На базе этого POC открыл собственно унылую компанию, которая вполне себе прибыльная.
На базе этого POC открыл собственно унылую компанию, которая вполне себе прибыльная.
Возможно, что автор комментария про Маска имел ввиду его ракеты и склонность к устраиванию фейерверков в двухнедельных циклах (спринты и демо?)
Т.е. все это может быть хорошо для тебя или твоего пет-проекта, но ужасно именно для бизнеса.Именно поэтому вместо коммерческих продуктов я стараюсь пользоваться open source.
В бизнесе важна скоростьИзвестная польская gamedev компания тоже так думала…
Это все попытки менеджеров-теоретиков-идеалистов привести все к идеальному и упорядоченному так как из-за отсутствия понимания им сложно оценить риски и тд.
Для меня PoC не больше чем условность принятая в конкретном случае для организации рабочего процесса. В природе не существует состояния «готово к прод», есть лишь понимание постоянно изменяющейся среды и удачно прижившихся решений)
Для меня PoC не больше чем условность принятая в конкретном случае для организации рабочего процесса. В природе не существует состояния «готово к прод», есть лишь понимание постоянно изменяющейся среды и удачно прижившихся решений)
Перевод слишком «машинный», особенно заголовок, в оригинале говорится что нельзя просто брать PoC в продакшен как есть или даже переработанным, нужно адаптировать идею, но не конкретную реализацию. Из самого переведённого текста это ещё можно понять, но заголовок уж слишком далёк от сути.
это не то же самое что и
равно как и заголовок
не является корректным переводом, хотя и дословен фразе
Я постоянно вижу, как разработчиков просят просто брать в продакшен их POC.
это не то же самое что и
I’ve seen developers asked to just put their POC into production.
равно как и заголовок
Почему никогда не стоит использовать Proof of Concept в продакшене
не является корректным переводом, хотя и дословен фразе
4 Reasons You Should Never Use Proof of Concepts in Production
Не используйте в продакшене POC, используйте нечто за подписью бизнеc-аналитика. Я все правильно понял?
НЛО прилетело и опубликовало эту надпись здесь
Выражу мнение, которое отличается от мнения большинства.
Существует ещё одна причина не переносить Proof of Concept в чистом виде в Production:
«У вас не будет второго шанса произвести первое впечатление».
Если я, к примеру, скачал новое (не путать с обновленным) приложение, оценил его, и понял, что оно слишком «сырое» и/или недостаточно функциональное, то я не буду ждать, пока его доделают — я уйду к конкурентам.
Конкуренты, как показывает личный опыт, тоже производят несовершенные продукты.
Поэтому я остановлю свой выбор на том приложении, которое ближе к идеальному, то есть из нескольких зол выберу наименьшее.
И дальше буду следить за обновлениями именно этого приложения, а не тех, которые установил и снёс.
В результате побеждает не скорость, а качество.
Сказанное относится и к Minimum Viable Product, на мой взгляд.
Во всяком случае, более десятка лет пользуюсь данным принципом, и ни разу об этом не пожалел.
И времени на выбор лучшего решения из всех имеющихся не жалко. Потому что это окупается, как в краткосрочной, так и в долгосрочной перспективе.
Существует ещё одна причина не переносить Proof of Concept в чистом виде в Production:
«У вас не будет второго шанса произвести первое впечатление».
Если я, к примеру, скачал новое (не путать с обновленным) приложение, оценил его, и понял, что оно слишком «сырое» и/или недостаточно функциональное, то я не буду ждать, пока его доделают — я уйду к конкурентам.
Конкуренты, как показывает личный опыт, тоже производят несовершенные продукты.
Поэтому я остановлю свой выбор на том приложении, которое ближе к идеальному, то есть из нескольких зол выберу наименьшее.
И дальше буду следить за обновлениями именно этого приложения, а не тех, которые установил и снёс.
В результате побеждает не скорость, а качество.
Сказанное относится и к Minimum Viable Product, на мой взгляд.
Во всяком случае, более десятка лет пользуюсь данным принципом, и ни разу об этом не пожалел.
И времени на выбор лучшего решения из всех имеющихся не жалко. Потому что это окупается, как в краткосрочной, так и в долгосрочной перспективе.
В одной большой компании, где мне случилось работать — эту проблему решали самым простым способом. Прототипирование новых продуктов шло на Ruby/Rails — а в продакшен разрешалось выкатывать только код на Java.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему никогда не стоит использовать Proof of Concept в продакшене