Поговорим о стартапах или так можно ли использовать стандартные движки, темы и дизайн?

    239.pngПриветствую всех читателей, сегодняшняя статья будет немножко необычной, в том плане, что тема будет поднята не совсем программистская, а скорее ближе к аналитической и бизнесовой. Поговорим мы о том, что же делать при начале своего собственного стартапа в сети Интернет, и попробуем рассмотреть один из самых популярных мифов (или нет?) о дизайне и движке вашего детища.

    И так, для начала рассмотрим само понятие стартапа, именно в контексте нашей беседы. Это создание веб-сайта или сервиса, который может:
    • иметь уникальный функционал, аналогов которого пока не существует, или он сильно разбросан по различным системам. То есть вы задумали что-то такое, чего ещё нет вообще (тип 1).
    • реализовывать уже существующий основной функционал, добавляя к нему отдельные возможности, расширяющие или переводящие использование уже известных функций на качественно новый уровень. К примеру, идея digg-сайтов не нова, но к стандартной возможности любому пользователю публиковать свои новости она добавила две функции, которые перевели уровень использования этого стандартного функционала (поста новостей) на качественно новый уровень (тип 2).
    • переносит уже существующие функции и/или сервисы в новую для них среду, позволяя открыть ранее не использовавшиеся рынки, например, если раньше выделенные серверы и файловые хранилища были уделом только бизнес-пользователей и корпораций, то сейчас с приходом продуктов вроде Microsoft Home Server или FreeNAS реализует все возможности на уровне пользователя и пригодно к развёртыванию и эксплуатации в домашних условиях (тип 3).
    • Агрегатирует функционал из разных, уже существующих источников, выводя новые возможности на основе комбинации существующих сервисов или улучшая использования оных (тип 4).

    Конечно, эта классификация не самая полная, но для наших целей вполне сойдёт. А дальше мы сосредоточимся на следующих вопросах:
    • собственная, полностью с нуля написанная программная система, реализующая функциональность стартапа против использования готовых движков, открытых или коммерческих, с частично доработкой и адаптацией.
    • Необходим ли собственный, полностью уникальный дизайн, или же можно использования свободно распространяемый шаблон или даже устанавливаемую по умолчанию тему оформления вашего движка.

    Первый миф самый распространённый. Его корни прочно растут из самой природы стартапа, который во многих случаях запускается именно технической командой, то есть, разработчиками, а среди них (да чего уж греха таить, среди нас, так как я тоже часто выступаю в роли разработчика, хотя все время переориентирую на именно управление проектами) распространено мнение, что кто-то другой, кроме них самих, обязательно написал или напишет ужасный, недокументированный и «глючный» код, поэтому лучше всего все выбросить с самого начала и создать то самое своё — и сразу получим самую уникальную и «чистую» во всех аспектах систему. Подогревается это ещё и массой примитивных комментариев в форумах и блогах, которые к постам о каким-либо разработками сразу навешивают устоявшиеся ярлыки «глючный отстой» и т.п., зачастую без реального знания и опыта использования этой самой системы, а просто «потому что Вася-программист так сказал за пивом». Вот и появляются расхожие мнения о «бажности» одних продуктов и «тормознутости» других, о криворукости индийских, китайских и всех остальных программистов-аутсорсеров, о постоянных дырах в безопасности того или иного движка (что, конечно не так и далеко от истины, но это просто конкретный рабочий момент, который не значит, что ПО Х нельзя использовать, просто нужно грамотно это делать). И, конечно, все программисты знают, как же написать именно ту систему, которая сразу решит все проблемы с безопасностью, нагрузкой и тому подобные задачи.

    Рассмотрим это со стороны управленческой, то есть, как руководители или владельцы того самого стартапа, а не программисты (которые, по сути и реальности, все же просто технический персонал). Если ваш проект относится к типу 1 (то есть, вы задумали исключительно уникальный функционал, который взорвёт рынок, или, что ещё лучше, создаст сам этот рынок), то да, по всей видимости, у вас единственный путь — это создавать своё программное обеспечение полностью самостоятельно. И то, так как любой проект, несмотря на уникальность, все же требует много стандартных возможностей, начиная от внутреннего функционала (вроде систем регистрации, доступа к СУБД, шаблонизатора и т.п.), и заканчивая внешними сервисами вроде блога проекта, сайта разработчиков, форума — это все логично отдать на откуп уже проверенным сторонним системам.

    А если вы строите стартап, который относится к типу 2 или 3, то самым рациональным будет все же выбрать из существующих систем самую близкую к вашей, исходя из перечня необходимых улучшений и изменений, а также руководствоваться такими критериями, как размер сообщества и уровень поддержки, качество кода и количество реализованных проектов на данном продукте, хотя в разных случаях бывает по разному — вполне возможно, что самый лучший для вас проект только что вышел в релизе и вам придётся основываться на альфа или бета версии, выступая, по сути, чуть ли не первым пользователем. Кстати, не нужно этого сторонится, и если функционал и другие критерии вас устраивают, вполне разумно будет использовать сторонние продукты (имеется ввиду проекты с открытым исходным кодом). Например, создавая новостной ресурс с дополнительной функциональность видео и аудио комментариями и рейтингом последний, логичным может быть использование уже зарекомендовавшего себя открытого движка блогов Wordpress, добавив в него несколько сторонних плагинов, реализующих дополнительные функции. Честно скажу, очень много действительно интересных и полезных проектов можно реализовать, просто собирая из кубиков — используя открытые системы, и наращивая при помощи комбинации из нескольких плагинов нужные функции. При этом сама по себе ценность ресурса никак не уменьшается! А вот затраты, особенно временные, существенно, часто на порядки, снижаются, а ведь именно время является главным и самым опасным врагом стартапа и всегда работает против создателей.

    Ведь даже самые простые расчёты могут обосновать для вас как менеджера проекта разницу в подходах — допустим, при самостоятельной разработке это:
    • детальное создание описания функциональности проекта — 1 неделя
    • детализация до уровня ТЗ на всю разработку и отдельные модули — 2 недели
    • разработка самого проекта — 3 — 10 недель
    • тестирование проекта — 1 — 3 недели (могут быть как размазаны по всем сроку разработки, так и ещё дополнительное полное тестирование в конце)
    • повторные доработки и исправление багов, разработка дизайна и т.п.

    Все это выливается в тысячи USD даже при сравнительно стандартном проекте, при этом я абсолютно уверен, что большую часть времени разработчик или команда будут тратить на создание и тестирование уже сотни раз созданных другими разработчиками компоненты. Вместо этого лучше потратить ту же неделю или даже две на обзор всех существующих систем или аналогов, установку их и первое ознакомительное тестирование, определить их соответствие списку требуемых от проекта возможностей и выбрать ту систему, на которой все будет основываться, а далее всего лишь создавать под неё дополнительные модули, которых явно меньше и трудоёмкость создания существенно ниже. Конечно, сейчас мне приведут аргумент, будто время, затрачиваемое на разбирание в архитектуре чужой системы чуть ли не равно времени разработки такого решения с нуля самому, и будут в корне неправы. Особенно это выгодно при повторном использовании того же решения в разных проектах, ведь разобравшись один раз, знания никуда не уйдут, а зачастую разбирания это чтение документации и просмотр кода с документированием, а разработка своего решения это совсем уже другой процесс. Кстати, есть и открытые проекты, качество документации которых заставит устыдится даже многих коммерческих разработчиков — посмотрите хоть бы на документацию к РНР фреймворкам типа ezComponents.

    А ведь как менеджера и владельца бизнеса, вас волнует что? Сроки запуска проекта, размер финансирования, реализуемость первоначального функционала, расширяемость и поддерживаемость в будущем. Вот последний пункт во всей красе как раз и выступает в случае использования готовой системы. Как вы думаете, сколько программистов могут сопровождать систему на, скажем, Drupal или Wordpress или Joomla? Верно, очень многие, так как комьюнити этих систем очень большое, как в Рунете, так и за рубежом, тогда как ваша собственная разработка, кроме повторения уже сотни раз созданного функционала будет содержать взгляд на мир именно вашего программиста и, в лучшем случае, комментарии и кое-какую документацию. Поэтому при необходимости заменить или просто расширить свою команду разработчиков вы будете искать человека со стандартными знаниями, а он, в свою очередь, будет разбираться только в нюансах вашей разработки и специфики, не погружаясь в недельные разборки с принципами и кодом всей системы.

    В общем, что сказать — если подходить к стартапу как к реальному бизнесу, и использовать вместо эмоций и типичного технического мышления критерии экономического характера и оценивать будущие ваши затраты (не только денежные, но и временные и человеческие), то в большинстве случаев вы увидите, что ваша задача вполне укладывается в функционал уже зарекомендовавших себя проектов, требуя для реализации всего лишь отдельных доработок, на которых и стоит сосредоточить все силы отдела разработки, вкладывая средства именно в то, что делаем ваш стартап уникальным. А пользователи, именно пользователи, а не комментаторы, не другие разработчики, не обозреватели новостных сайтов и блогов — приходят на сайт и используют размещённую там информацию, полезную для них, и им, в конечном счёте абсолютно все равно, на основе какого ПО или языка написана эта система. Ну, к примеру, почти каждый пользователь хоть раз посещал проект Wikipedia — и как то, что она создана на основе движка (вернее, её движок используется как свободное ПО и на нем основаны сотни других проектов) MediaWiki, а в основе использует распространённый РНР и СУБД MySQL — как это повлияло на ценность и восприятие информации? Думаю, что никак. И заходя на веб-сайт браузера Mozilla Firefox, мало кто знает, что он построен на базе стандартного движка Drupal — а ведь уж такое сообщество и компания как Mozilla могла бы сделать попутно и свой движок. Но не сделала, направив все усилия на развитие основной инфраструктуры и проектов, которые и являются основной их бизнес-процессов. Но вот почему-то обозреватели и критики любят подходить с критерием оценки проекта как «если он написан на стандартной системе Х, то на него никто не будет поэтому ходить/пользоваться». Какая связь между этими тезисами — никто пока не рассказал. Более того, именно выбор стандартной системы, в большинстве случаев open-source для запуска стартапа является именно показателем логичности и разумности мышления менеджмента, и показывает, что в основе все же стоят вопросы функционала и качества работы, а не абстрактные тезисы о том, что «лучше хуже, но своё» или банальный «распил» халявных денег не учитывающего специфики инвестора. И лишь в немногих, я специально подчеркну, немногих случаях требования к функциональности проекта определяют необходимость разработчики своего уникального решения.

    Еще раз, краткий оптимальный план действий:
    • Составляем перечень функциональности нашего стартапа
    • Анализируем рынок существующих разработок, выбирая список проектов, которые могут стать основой проекта
    • Рассматриваем каждый проект в разрезе соответствия нашему «фич-листу», наличие поддержки или комьюнити, качество документации и т.п.
    • Стараемся выбрать тот продукт за основу, который больше всего реализует из наших требований, или реализует именно ключевые функции.
    • Фокусируем средства и разработчиков на создание дополнений и расширений, доводя сторонний продукт до наших требований, максимально используя стандартный функционал.
    • И только в случае отсутствия реальных аналогов или же полной уникальности создаваемого проекта переходим к самостоятельной разработке, которая, кстати, также должна начаться с точно такого же плана, только рассматривать следует уже не готовые продукты, а компоненты и средства разработки — фреймворки, наборы компонент, сервера и сервисы и т.п. сугубо низкоуровневые детали).

    Все, на сегодня завершим наше обозрение, завтра будет продолжение.

    P.S. По сути, эта статья как ответ критике здесь и в частных разговорах моего последнего проекта — DevLinks.com.ua
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 79
      0
      автору спасибо за работу. жду продоления.
        0
        Достаточно объективно все написано. Спасибо!
          0
          спасибо за отзывы! Рад, что понравилось, завтра, в крайнем случае - в понедельник будет продолжение.
            +3
            О Друпале в контексте изложеного:
            действительно, большую часть популярного функционала можно реализовать используя готовые модули как "кубики". Пичем, необходимого схожего результата можно добиться используя различные наборы кубиков-модулей, что есть достоинством и, в некоторой степени, недостаком. Таких дополнительных (contributed ) модулей у Друпала свыше 500, около трети из них активно дорабатывается и содержат несколько версий (dev и stable для разных версий ядра). У модулей появляется и изменяется API для интеграции с другими модулями. Нетривиальный функционал (например digg-like)на данный момент реализуется связкой из 6-8 сторонних модулей (часть не stable) от разных авторов, один из которых, кстати, "забил".
            Веду я к тому, что необходимо уделять не мало времени на отслеживание новых версий модулей, их API, списки багов и реакцию разработчиков на них.
            Но все-таки, если вы работаете один или у вас маленькая команда - OS CMS/CMF правильный выбор.
              0
              полностью с вами согласен, по сути это материал отдельный по стратегии выбора ЦМС... но в общих черта именно так.
                0
                В модулях (и их количестве, которое как известно переходит в качество) сила друпала. Меня больше волнует отказ от использования новых возможностей php5 (OOP)(хотя это будет уже не друпал :) Использование таблицы sequences вместо auto_increment, и html размазанный по всему коду.
                  0
                  >отказ от использования новых возможностей php5 (OOP)
                  легкость, друпал поднимается на стреднестатистичеком shared -хостинге;
                  >таблицы sequences вместо auto_increment
                  на это есть основательные причины;
                  >html размазанный по всему коду
                  любой тег/элемент легко можно переоптеделить.

                  вы поклоннийк MVC? Мне тоже нравятся эти буквы.
                +1
                Спасибо за интересную статью.
                Aleks_raiden, возможно, вы сможете посоветовать, как именно менеджеру (не техническому специалисту) выбрать среди множества предлагаемых cms, не прибегая к помощи программиста? Передо мной сейчас стоит именно такая задача.
                В списках, представленных на сайтах типа cmslist.ru я теряюсь :) там этих cms'ок десятки
                  0
                  напишите в личку или по контактам с профайла, расскажу.
                    +1
                    Совсем не прибегая к помощи — нельзя. Если программисту потом работать над интеграцией этой CMS — к его мнению тоит прислушиваться (и хоть какое-то доверие к своим разработчикам нужно иметь).
                      0
                      да, конечно, для выбора нужны специфические технические знания. но их нужно правильно организовать и, скажем так, верно задавать вопросы чтобы ответы помогли выбрать а не запутали :)
                    +1
                    трезво написано. продолжай :)
                    еще интересно былобы узнать побольше на тему проблемы курицы и яйца. сайт без пользователей - потенциальным пользователям неинтересен. какими найменее затратными путями можно получить начальных пользователей?
                      0
                      автор случайно не менеджер проекта однокласники.ру?
                        0
                        Тот Алекс Грифин. Человекобренд.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            а кроме как то же писать в комментариях вы не можете ничего больше? аргументы есть?
                            • НЛО прилетело и опубликовало эту надпись здесь
                                +1
                                ну так как большинство поступают точно наоборот, то видимо это не такая уж распространённая мысль. а можете ли вы много или мало, этого никто не знает, пока не сделаете и не покажите. пока же можете просто писать комментарии и, как бы это сказать, просто ведёте пустые разговоры. есть что сказать по теме факты или аргументированное мнение - говорите.
                                • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              расскажите почему?
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  +1
                                  о! тут вы правы, но вот вывод неверный. Ваш бизнес - создавать ПО - тогда да, вы правы, ведь наколировав модуль, допустим, реализующий анализ коментариев по нечёткому словарю на наличие матёрых слов, вы создали продукт и ту самую вашу добавленную стоимость (кстати, а к чему эта стоимость добавленная, на входе, в отличие от материального производства, не было ничего). Но если ваша задача обеспечить _сервис_, то, заметьте, это не то совсем понятие, и ценообразование и бизнес-модель _сервиса_ отличается от такой же модели для бизнеса производственного (что бы он не производил - тапочки или компоненты для ASP.NET).
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Полагаю, что подавляющее (именно подавляющее) большинство старапов гибнет потому, что у разработчиков небыло досель никакого опыта собственного бизнеса :)
                                      То бишь они не то что "не осознали разницы между цифр/нецифр", а просто впервые столкнулись с бизнесом вообще.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          нет, она есть, просто это понятие более глубокое, чем его бы рассматривать в контексте обычного бизнеса по продаже семёчек в людном месте или выпечке домашних булочек на продажу на рынке :)
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    кроме этого, есть кстати, ещё и понятия минимализации издержек производства, в данном случае речь идёт о разумной минимизации издержек на развёртывания базисного функционала, о чем (минимализации) бизнес тоже не меньше печётся. поэтому стоит сначала проанализировать, _что_ приносит доход, что лежит в основе вашей конкретной бизнес-модели, а тогда уже переходить на определение добавленной стоимости и к чему она прилагается.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                +7
                                прочитал с интересом. по ходу прочтения с некоторыми вещами был не согласен, только по окончанию понял что Вы говорили о ЦМС системах. Я не любитель таких вещей, в силу того что у меня уже есть достаточно большой опыт в разработке, наборы модулей и достаточно стабильные (многократно обкатанные) версии своих фрэимворков для PHP.
                                Я согласен в тем, что найти разработчика со знаниями известной ЦМС системы намного проще чем разработчика который сможет доработать кастомную систему. Но тут есть одно "но". в основном с ЦМС системами работают люди с малым опытом, поэтому найти человека который сможет что-то доработать Вам будет проще, но профессионал сможет работать с чем угодно. :) тут и разница - профессионал сделает лучше и подумает наперед.
                                ЦМС системы безусловно хороши для небольших проектов, при стандартных модулях и скромных аппетитов заказчика :)
                                Но как только аппетиты начнут расти, не факт что Ваша система будет по-прежнему удовлетворять Вашим потребностям. Например одно дело использовать Smarty в своем фрэимворке. А совсем другое дело использовать готовый движок. Проблема в том, что вы зависите от выранного Вами движка. и если сегодня вы запустите стартап на версии некоего движка 1.1, а завтра выйдет версия 2.0, несовместимая с предыдущими (что бывает достаточно часто), то Вы останитесь не у дел. и придется любыми силами переходить на 2.0 чтобы иметь возможность найти разработчиков знающих Вашу систему. Еще, довольно важный момент всех этих вещей - в любой момент может появиться security bug report на сайте разработчиков Вашего движка. И какие-нибудь недоброжелатели могут им воспользоваться. Имея кастомную систему (пусть намного более несовершенную), все тараканы останутся внутри, и как следствие Вы сможете быть более спокойны в плане безопасности существования Вашего проекта.

                                Я хочу еще привести несколько причин, почему разработчики предпочитают изобретать велосипеды, вместо использования готовых ЦМС систем. Я согласен, что зачастую на небольших проекта правильнее использовать готовые решения.

                                1. ЦМС системы, взять тот же eZ (пусть фанаты этого монстра не обижаются), но он жутко тормознутый
                                2. Для большого проекта, профессионалу лучше использовать хороший enterprise framework
                                3. банальное - разработчикам легче отвечать за свой код, чем за то что сделали не они (не хочется исправлять чужие баги, угадывать что думал разработчики движка и почему так, а тем более им не хочется разбираться с большой ЦМС, а это нужно, потому как они должны знать что, где, как и почему. для того чтобы в адекватные сроки быть в состоянии оказать поддержку)
                                4. ЦМС системы очень удобны снаружи и очень сложные и кривые внутри. Из-за большого количества модулей они намного медленнее переходят на более новые версии языков программирования и баз данных.
                                5. Часто, возможностей модулей недостаточно и их приходится расширять
                                6. У разработчиков могут быть свои серьезные, похожие наработки

                                Ну и в заключение, не все заказчики хотят чтобы их проекты делались на известных ЦМС. не знаю почему :) Но как мне кажется, популярные движки и их модули хотят использовать те кто хочет побыстрее и подешевле.

                                А в целом, статья мне понравилась, Ваш сайт я еще не смотрел, но обязательно загляну. Было бы интересо продолжить дискуссию, ведь в споре рождается истина
                                  0
                                  В беседе рождается истина :) В споре чаще рождаются обиды :)
                                    0
                                    это верно :) ну про спор это просто выражение такое
                                    0
                                    Вы написали достаточно неплохой и взвешенный комментарий, озвучив некоторые мои мысли. А я, пожалуй, смогу немного прокомментировать ваши.

                                    Очень верно, но без необходимого акцента, подмечено про bug lists: на самом деле, когда проект висит на популярном движке - нужно постоянно следить за обновлениями версий ПО, на котором работает проект. Неоднократно бывали случаи, когда на "хакерских" сайтах публиковались уязвимости известных решений (например, небезызвестный phpBB) - и посетители кидались проверять эту дырку на известных им сайтах на этом решении. А как вы знаете - попросить у гугла вывести ему список сайтом на таком-то движке не очень сложно.

                                    Отсюда можно сделать вывод - что для поддержания такого проекта этому аспекту нужно уделять большое внимание: если ты up-to-date, то ты на коне. А качественно и ответственно этим может заниматься только подготовленный человек, в лучшем случае - профессионал. И тут же - могут появляться проблемы с обновлением движка, переносом на новый и так далее: из-за того, что "что-то" доработали.

                                    По поводу заказчиков и известных решений: во первых, продавать заказчику решение, построенное на базе open source, достаточно спорно. Ведь, по большему счету, open source предназначен для непосредственно для open source. Тут есть тонкая грань - целиковое решение или какие-то компоненты или библиотеки: последние, само собой, используются повсюду.

                                    Заказчики в большинстве хотят получить решение, созданное специально для них. Отчасти может из-за того, что они понимают, что платят деньги за труд, результатом которого будет решение, созданное специально для них. И разработчики, как было отмечено выше, смогут его итерационно доработать до необходимого уровня (если это, конечно, оговорено в договоре) - со своим кодом это делать гораздо проще.

                                    Вообще это всё палка о двух концах, как и многое в этом мире )
                                    –2
                                    Похоже на раскрутку очередного стартапа на дырявом движке Pligg с помощью якобы актуально статьи и за счет авторитетности хабра
                                      –5
                                      минусуйте, минусуйте, правда режет глаза? стыдно за хабр
                                        0
                                        Знаете - статья сделала свое дело, раз заставила вас реагировать. Она же не обязана решать какую-то проблему, она может наталкивать на мысли и на обсуждения :D
                                          0
                                          Ну автор так громко заявил о использовании для стартапа стандартных(я так понимаю бесплатных) CMS, а сам налил несколько абзацев философско-экономических размышлений. Я не увидел тут ничего полезного не для новичка не для профессионала.
                                            0
                                            Поверьте, доля правды там есть. И я думаю, что хотя бы некоторым это будет познавательно - ведь известный факт, что многие программисты не разбираются в экономике - может кого-то статья натолкнет на размышления по этому поводу.
                                      0
                                      ну тут ещё надо заметить, что сам по себе опенсорсный движок - это не банальность :) Банальностью в 90% случаев является то, что на этом движке поднимают. Клонированные бложики о заработке в сети (хозяева которых сами надеются заработать в сети) уже стали притчей во языцех :)
                                        0
                                        Пример мозиллы на друпале показателен лишь в случае, если веб-сайт используется только для донесения конечного продукта(софта) до пользователя.

                                        А вообще, у меня сложилось мнение, что использование существующих CMS уместно только в случае сайтов, у которых не предполагается особое расширение функционала.
                                          0
                                          Существующие движки можно и нужно анализировать на наличие удобных вещей, чтобы улучшить свой, в котором ты точно знаешь как что работает. А использовать можно только для мелких проектов не отличающихся большой оригинальностью от множества других.

                                          Уникальные вещи создаются собственноручно.
                                            0
                                            Virtual_GOD и Silenius - ответ вам занял бы страницу, наверное :) можно использовать цитаты с ваших комментариев для развёрнутого ответа в продолжении материала?

                                            PIT - вы правы, но если заметили - речь идёт именно об уникальный проектах, когда аналогичного функционала _нет_. во многих других случаях решается задача создать сервис, а программисты решают то что им ближе - пишут код, ЦМС, тогда как задача бизнеса все же получить работающий _сервис_. разницу понимаете?
                                              0
                                              конечно :)
                                                0
                                                Будет интересно, что получится. На самом деле, я отвечал на комментарий, по теме у меня есть еще много чего сказать. За один раз не получается )
                                                0
                                                Что-то я не совсем понял. Это перевод старой англоязычной статьи? Не знаю кто как, а я уже живу в конце 2007 года и достаточно наелся "стартапами", в которых всё начинается с "детального создания описания функциональности проекта" :-)) Ёлки-палки, ну что за ересь? Какой смысл обсуждать разницу между CMS, если сначала нужно сделать бизнес-модель? И второе: если нанимать программистов за 1000 долларов, то они сколько угодно будут кормить вас сказками о разнице между Друпалом и Джумлой, говорить много умных слов на тему open-source community и прочем. А стоит только начать нанимать специалистов и платить им нормальные деньги, разговор наконец-то пойдет о другом: о том, насколько выбранный язык отвечает принятому технологическому стандарту производства, о стоимости моделирования функционала, о стоимости внесения изменений, о планируемом проценте риска при расчёте стоимости кастомизации и т.д.
                                                  0
                                                  так мы не о ентерпрайз системах говорим то. твиттер как начинался? и все остальные проекты. давайте не путать области. и даже в тех проектах нужно описывать функционал, разве что вы сразу поставите оракл и там вам будут за 10К специалисты-внедренцы и аналитики за вас придумывать а как же вы будете с ним работать.
                                                  0
                                                  Ваши сроки разработки немого не те что у Брукса
                                                  http://webkomora.com.ua/ru/articles/web/management/man-month/18.html

                                                  2.8 Мое практическое правило: 1/3 времени - на проектирование, 1/6 - на написание программы, 1/4 - на тестирование компонентов и 1/4 - на системное тестирование.
                                                  -Заявление мифического человеко-месяца -
                                                  Столь размытый период проектирования - разработки у Вас, это практический результат?
                                                  Кажется первый пункт я бы снял вообще, так как к подобным разработкам он не имеет никакого отношения.
                                                    0
                                                    Брукс писал верно, но совсем для других проектов и реалий. у меня пример очень общий, это _не_ конкретные сроки а скорее просто иллюстрация.
                                                    0
                                                    Если вы менеджер, которому главное только чтобы всё было подешевле и побыстрее запущено, без взгляда хотя бы на год вперед – вас надо уволить. Для запуска чего-то маленького самому или с другом ваша схема вполне подойдет, не более.
                                                      0
                                                      Это как панельный и кирпичный дом. Дешевле и быстрее панельный, но предпочитают все кирпичный. (при прочих равных)
                                                        0
                                                        к сожалению, в данном случае ваша аналогия не подходит.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                          –2
                                                          Стартап на Битриксе! Падсталом! :) Легче из г@#№а конфетку сделать.
                                                            0
                                                            Все можно сделать на чем угодно. И на битриксе и на пхп-нюке. Главное с умом подойти к делу...
                                                              –1
                                                              С умом, это когда инструмент соответствует задаче. Нюк и Битрикс - палец и жопа.
                                                              0
                                                              мне всегда казалось, что "старт-ап" это характеристика состояния проекта, а не его технической сложности.

                                                              Те же одноклассники до последнего воемени (да и сейчас во многом) ты было очень убогое технически решение. Чего только стоила ненормализованная база учебных заведений!
                                                            0
                                                            Продолжаю флудить...
                                                            Делать стартап на CMS - все равно, что говорить пословицами.
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                              0
                                                              Во втором параграфе описан не стартап а уголовно наказуемая торговля инсайдерской информацией. А тут речь о вэбе.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  0
                                                                  Да я в курсе, что стартапы бывают разные. Но тут (поправьте меня, если я неправ) рассматриваются те, для которых сайт не инструмент бизнеса а сам бизнес и есть.
                                                              +1
                                                              Да что вообще спорить? Возьмите, да и попробуйте создать с нуля свой первый проект. И сразу все точки над i будут расставлены - у кого-то пойдет, а у кого-то нет. Программисты или бизнесмены - каждому свое, каждый делает то, что умеет. Умирают стартапы ИМХО потому что всегда чего-то нехватает. Программеру нехватает навыков бизнесмена (сеошника), бизнесмену надо нанимать программера и т. п. Плюс не все готовы продать квартиру и кинуть все деньги на рекламную кампанию :-)))
                                                              А если серьезно, интернет-сайт (любой) - это тот-же киоск в реале. У него есть хозяин и товар (контент). Кто-то сможет вывести его на уровень огромного и дорогого супермаркета, а кто-то так и будет торговать сигаретами. Третий вообще поймет, что это "не его" и продаст его нах. Поэтому если вы хотите создать свой проект, да еще чтобы он был востребован и приносил деньги - не жадничайте временем, составьте "бизнесплан" и подробно все распишите, начиная от того, сколько народу будет задействовано в работе и заканчивая цветом ссылочек в подвале страницы. И подсчитайте все затраты.
                                                              А сейчас мы наблюдаем в основном такую картину. Сидит человек в сети и думает, как бы денег поднять? Чаще по призванию это программисты, а не бизнесмены. И начинает этот человек, слепо веря в свои силы (и не безосновательно - он хороший программист) тупо с нуля строить свой сайт, в надежде на то, что завтра "озолотится". Но так не бывает - это в первую очередь бизнес, а уже потом IT.
                                                                0
                                                                отличный и верный на 100% комментарий.
                                                                0
                                                                Интересно бы понять, вот просто навскидку, какие CMS можно было бы использовать, чтобы создать...ммм... хотя бы аналог Хабра?
                                                                Мне кажется одних Друпалов и Плиггов будет маловато, имхо.
                                                                  0
                                                                  да а чего в хабре есть уникального? ничего ведь. уникальность может быть в алгоритме оценки и реакции на отдельные параметры (карма там и т.д.), так что с определенной доработкой и друпал и плигг вполне заменяют, да и добавили бы ещё возможностей (чего стоит убогий совсем и с глюками в ФФ интерфейс создания новой записи, все же 2007 год, а выглядит совсем уж убого).
                                                                    0
                                                                    А кто-нибудь что-нибудь может сказать о open source движке Elgg?
                                                                    http://elgg.org/
                                                                      0
                                                                      у меня за три попытки даже не установился на тестовом сервере :( но другие используют. одна из немногих реализаций соц.сетевого движка опен-сорсная
                                                                        0
                                                                        Ок, спасибо :)
                                                                        Очень хороший пост. Заставил задуматься о многом.
                                                                      0
                                                                      я имел ввиду, что технически нет уникальных и нереализованных нигде функций и возможностей.
                                                                    0
                                                                    Хорошая статья.
                                                                    Правда есть еще один важный момент, что стоит высветлить.
                                                                    Необходимо также оценивать трудоёмкость в соотношении к требованиям расширяемости модуля или продукта.
                                                                    Часто для простых объектов, что или не будут активно расширяться или будут, но вне пределов функциональности продукта всё-же оптимально писать свою систему.
                                                                      0
                                                                      А вот есть ли варианты, чтобы купить CMS, но недорого (может кто покупал и пользовал)?
                                                                      Например, за $100-400. Ну саппорт чтобы был и прочее...
                                                                        0
                                                                        1. важно чтоб вы понимали, что в стоимость CMS не входит разработка, внедрение и сопровождение сайта на ней. Вы покупаете коробку интрументов с некоторой гаратией на них - остальное - ваша забота либо докупать кастомизацию, дизайн/шаблон и т.д.
                                                                        2. поддержка CMS и подержка запущеного сайта - разные статьи расходов.

                                                                        Популярные открытые CMS также имеют платную поддержку (местами качественней), например http://drupal.org/paid-services
                                                                        + у вас будет возможность выбора из желающих помочь за денежку (поторговаться) в отлчии от.
                                                                        0
                                                                        Еще один момент - популярные open-source системы обновляются десятки раз в год, чего себе не могут позволить многие коммерческие системы. Плагины также обновляются и тоже довольно часто. Как-то скачал, установил плагин к ВордПрессу (голосовалку), а пока пришло время сдавать клиенту работу (2 дня) он уже обновился ;)
                                                                          0
                                                                          ИМХО юзать 3rd party типа wordpress или тем более какой-то IPB для посещаемый проектов для тех, кому не жалко денег на новые сервера. Для дом страниц и небольших форумов (до 500К хитов в сутки) конечно хорошо, но продакшн-системы что расчитаны на высокую нагрузку, имхо, стоит проектировать несколько по-другому, чем wordpress (я знаю про существование плагина кеширования, если об этом зайдет речь).
                                                                            0
                                                                            то есть, не нужно использовать готовые, опен-сорс решения, например мемкешед, РНР, тот же MySQL, SymmetricDS, XSLCache, DBSlayer - да? А если вы посмотрите на сайте http://highscalability.com/welcome-high-… то увидите, что почти все гиганты использую очень много всего открытого и бесплатного. Те, кто делают опен-сорс проекты они же тоже разрабатывают свое и архитектурно готовое к высоким нагрузкам. И если я делаю такую систему, сдаю клиенту и открываю код, то что, такая система сразу стает чем-то хуже?
                                                                              0
                                                                              Я не о том опенсорсе и возможно и не об опенсорсе вообще (IPB - насколько я знаю не имеет бесплатных версий.. хотя могу и ошибаться).
                                                                              Я о движках сайтов и форумов вроде Вордпресса, IPB, DLE итд.
                                                                              А php, memcache итд использовать очень даже можно и нужно. Но архитектуру сайта надо строить самому (ну или найти решение именно для очень посещаемых сайтов, где страницы не генерятся на лету в большинстве случаев)
                                                                                0
                                                                                Зачет за линк.

                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                            Самое читаемое