Софтверная компания
Собственно есть желание собрать команду и основать софтверную компанию. Начать с разработки небольших программ. Акцент сделать на скорости разработки (до 3 месяцев на пилотный проект), качество и надёжность продукта. Ограничение на время разработки проекта с одной стороны увеличивает шансы его завершения, с другой стороны накладывает ограничения на функционал— только то, что действительно нужно и ничего лишнего.
------------------------------------------------------------------------------------
№20: Сформулируйте тему
...
Согласно Паркеру главным принципом является гармония (unity). И я, раз за разом, наблюдал, что гармония является и главным принципом качественного ПО. Адаптируя объяснение гармонии Паркером, мы получаем следующее определение. В продукте, обладающем гармонией, каждый элемент существенен для целого и все существенные элементы присутствуют. Из этого определения вытекают следствия. (1) Так как все, что нужно клиенту, есть в продукте, то пользователю ничего кроме продукта не надо. (2) Так как в продукте нет ничего лишнего, то вхождению клиента в мир продукта ничего не мешает.
...
------------------------------------------------------------------------------------
Цитата из книги Джима Маккарти, Мишель Маккарти «Правила разработки программного обеспечения».
Естественно само собой дело не пойдет, нужно серьезное отношение к делу: проектирование, планирование разработки (составление планов и графиков работ), создание бренда, маркетинг. Начать, я думаю, можно с портфолио— сделать пару пилотных проектов, чтобы проверить возможности и работоспособность команды: как идет проектирование, планирование, разработка, тестирование, маркетинг. Если команда окажется эффективной и сможет произвести на свет пару пилотных проектов (эффективность разработки), если удастся заявить о себе (актуальность разработки и эффективность маркетинга), то, я думаю, либо найдутся коммерческие заказы, либо можно будет продать и развивать пилотные проекты, т.е. превратить их во вполне реальные проекты.
Сфера деятельности (на выбор):
а) ориентация на массового пользователя: создание программ которые могут быть полезны обычным пользователям в домашних условиях.
б) системы автоматизации: программы для фирм, которым нужно автоматизировать какие-либо бизнес-процессы.
в) сетевые приложения: разработка Интернет и intranet приложений.
г) веб-студия: создание сайтов и веб-приложений.
Инструменты:
Я думаю стоит сделать акцент на кроссплатформной разработке (для Windows, Linux, Mac), следовательно использовать инструменты предоставляющие такие возможности: C++/QT, FreePascal/Lazarus, PHP, Python, Ruby, MySQL, PostgreSQL и т.д. Перечень инструментов можно будет уточнить когда будет собранна команда. Тем кто предпочитает покупать и использовать Windows, мы будем предлагать Windows версию, тем кто хочет сэкономить — Linux-решения.
Набор команды:
Если кого-то эта тема заинтересовала и желает присоединиться— пишите, можно считать, что я уже пробую собирать команду и собираюсь предложить трём своим друзьям войти в команду, если они того пожелают. Если они согласятся, то нас будет уже как минимум четверо. Студентами я не брезгаю, даже напротив— главное чтобы были талант и хоть какие-то начальные умения и знания.
Условия работы:
На старте удаленная работа, гибкий рабочий график, совмещение с основной работой или учёбой, преимущественно работа по выходным. После удачного запуска возможна удаленная работа на дому или работа в офисе, полная или частичная занятость, по выбору. В любом случае главное чтобы был результат, всё остальное не так важно.
Комментарии: 23
Отличная идея :)
1. рекомендую все же вам сосредоточиться на той экспертизе, которой обладают все участники. Иначе качества вы не добьетесь, поскольку придется наступать на грабли и подводные камни. А у вас там слишком большое разнообразие инсрументов и платформ.
2. обязательно подумайте об организации процесса, привлечении аналитиков (если нужно) и тестировщиков (просто обязательно). По личному опыту скажу, что с удаленными участниками команды отлично можно работать, но нужен хороший инструмент по постановке задачи и контролю их исполнения, тем более что вы хотите работать с ограниченными во времени проектами. Я лично использую DEVPROM, установленный на собственном сервере и интегрированный в subversion. Команда: москва, нижний, смоленск. Заказчик в Москве. Завершаем уже третий проект (среднее время на проект 7-8 месяцев), система отлично помогает прогнозировать сроки завершения с учетом возможностей команды.
Если нужны детали, то готов подробнее рассказать и показать.
Заметка слишком маленькая чтобы описать всё, она и так слишком длинная получилась.
> А у вас там слишком большое разнообразие инсрументов и платформ.
Ествественно когда будет собранна команда их число сократиться. Просто сейчас не берусь предсказывать кто войдёт в команду и об этом сказано в заметке.
> обязательно подумайте об организации процесса,
Сейчас думаю, обкатываем одну идею, мы даже тулзу для этого написали, чуть позже сделаю анонс. Можно считать что наш первый пилотный проект. Сейчас готовим релиз, проблема с маркетингом — пока не знаем как.
> тестировщиков (просто обязательно)
безусловно, это так очевидно, что я даже не писал об этом :-)
> По личному опыту скажу, что с удаленными участниками команды отлично можно работать,
я сам работаю удалёно, поэтому так уверен, в том, что мы сможем работать удалённо.
> но нужен хороший инструмент по постановке задачи и контролю их исполнения
ага, см. выше, ждите релиза Schedule Manager
> Я лично использую DEVPROM, установленный на собственном сервере и интегрированный в subversion
ага, работаем на базе Шаманграда (наш проект, мы вами в этом плане конкуренты...)
> система отлично помогает прогнозировать сроки завершения с учетом возможностей команды.
Было бы инетерсно услышать/увидеть подробности
«ага, работаем на базе Шаманграда (наш проект, мы вами в этом плане конкуренты...)»
ну скажем так, не прямые, ходя кое-какие идеи схожи, может быть просто объединим усилия? :)
«Было бы инетерсно услышать/увидеть подробности»
Насчет увидеть, все просто, на сайте море описалова всякого, а так, создайте себе проект и все увидете. Мы делаем упор на профессиональной разработке, а не на багтрекинге, думаю вам должно быть очевидно, насколько это разные вещи.
А если «услышать», то писать можно много, задавайте вопросы, я отвечу.
> Мы делаем упор на профессиональной разработке, а не на багтрекинге, думаю вам должно быть очевидно, насколько это разные вещи
У меня тоже планы были большие, в итоге пока осилил только багтреккер, в планах были ещё несколько подсистем. Вы просто дальше ушли, так что в этом респект вам.
> может быть просто объединим усилия? :)
Может быть, сначала буду приглядываться ;-)
Ok,
у меня появилась отличная идея: почему бы вам не вести проект с использованием DEVPROM? :)
пять бесплатных пользователей, два проекта. Если понравится, то бесплатно обеспечим еще :)
на мой взгляд у нас сильно разные ниши.
Она быть может отлична для вас — «опа, очередной клиент»
Но наверное не столь отлична для меня — «вот блин, ещё один инструмент на освоение которого ещё нужно потратить время», если собственного функционала будет не достаточно, то обязательно будем искать что-то на стороне.
Я изначально давал совет ее использовать, потому что без нее у вас будет много проблем, как были у нас.
Следовать совету или нет — это конечно вам решать :) но багтрекер для разработки совсем не годится :)
конкурент, это уже похоже на навязчивую рекламу :-)
Да нет же, я как рукодводитель группы распределенных разработчиков говорю. То всего лишь инструмент для решения конкретных задач.
> Насчет увидеть, все просто, на сайте море описалова всякого, а так, создайте себе проект и все увидете.
Вопрос во времени, которого последнее время ни на что не хватает и уж тем более не хватает чтобы разгребать стог сена в поиске очередной иголки. Вы ж писали, сами должны знать, какой ссылкой лучше ответить по вполне конретной теме.
Хороший топик у меня такая идея паралеллельно вертится с web стартапами. Есть и идеи некоторые. Интересно бы найти инфу по ёмкостям рынка ВЕБа и обычного ПО.
Про комент девпрома, а маркетинге и экспертизе рынка — респект. Это очень важно чтобы не бурить никому не нужные направления. В технологиях забыли java конечно.
Я готов поучаствовать в обсуждениях, и возможно на более поздних стадиях подключиться.
Что бы хотел заметить, в средней перспективе надо думать о том что результат можно продавать в несколько мест с небольшими кастомизациями. Т.к. одиночная разработка — это не очень эффективно.
Т.е. в итоге софт либо интернет сервис.
вообще предлагаю всем желающим писать. пусть наберётся 15-20 людей. которые договорятся по технологиям, сферам. образуют в итоге 5 команд по разным направлениям и начнут работу. параллельно можно общаться на базе СП.
ы, будет 5 отделов, в случае сложного проекта будет объединить несколько команд.
Например, есть команда хорошо работающая с GUI и есть комада хорошо работающая с сетевыми приложениями, в случае необходимости можно объеднить, точнее распределить задачи — программу-клиент с графическим интерфейсом будет делать одна команда, сервером будет заниматься другая команда.
Все будут работать эффективно, над тем, что нравиться, и все будут счастливы :-)
Эх… пока только мечты :-)
но может быть, когда-нибудь…
Это хорошо, что вы решили организовать софтверную компанию. Но одного желания мало.
1. Любая компания должна приносить деньги, а деньги нужны, чтобы платить работникам. Несколько человек на одном энтузиазме далеко не уедут. 1 может, ну 2 может… но 5 вряд ли. Команда развалится еще в самом начале, через месяц.
2. На чем собственно вы собрались зарабатывать? Вы хотите писать софт, но какой и для чего — не понятно. Кроме того, без вас уже тысячи других разработчиков со своими проектами, во всех перечисленных вами областях. Вы сможете конкурировать с ними?
3. Большой коллектив удаленно работать может… а может и не работать. Тут нужен сильный менеджер проектов, который будет постоянно контролировать всех, пинать и ставить задачи. Без этого никак.
В общем, лучше вам додумать свою гениальную мысль, конкретизировать и поставить фиксированные цели.
не надо ничего конкретизировать на мой взгляд.
идея в том чтобы собрать заинтересованных людей. а думать и конкретизировать потом вместе. — так быстрее.
всё кончится попойкой без какого-либо продолжения. Людей надо собирать с целью. Просто собирать людей чтобы подумать — бесполезная затея. Большинство людей — исполнители, им выбирать цели вообще противопоказано. Поэтому для начала должен быть организатор, который поставит людям ближайшую и дальнюю цель, соберет народ, простимулирует и пнет куда надо.
В нашей команде вас не будет :-)
Цели есть, задачи есть, двое из трёх уже согласились войти в команду (нас уже трое), третий ещё не ответил.
Итого нас уже трое. Ещё до этой статьи мы (в двоём) делали одну тулзу (Schedule Manager), сейчас готовим релиз (ждите анонса, будет на следущей недели, может чуть раньше) — будет первый пилотный проект. Уже есть мысли относительно второй версии.
Наша первая цель, не захват рынка, сбор и проверка работоспособности команды. Если команда окажется работоспособной, докажет свою способность достигать цели, то мы сможем взяться за что-то более серьезное. Если же команда окажется неработоспособной — ну мы ничего не теряем.
Кто не пробует, не рискует, тот не пьёт шампанского :-)
На самом деле у меня очень часто возникают идеи, сделать то или другое. У других, талантливых программистов, на сколько я могу наблюдать тоже. Проблема в том, что зачастую одному человеку нереально реализовать такие идеи, поэтому и нужно объединять усилия (что очень сложно), пытаться реализовать идею как можно быстрее, пока не пропал энтузиазм. Если команда сильная, сплоченная, то это возможно.
Я думаю, что недостатка в идеях не будет, скорее будет переизбыток — надо будет как-то оценивать ситуацию и перспективы реализации того или иного проекта (делать анализ, как предлагали выше), после чего выбирать наиболее перспективные и реализовывать их.
И ещё главное не стоять на месте. Даже если нет гениальной идеи, то нужно реализовывать просто прикольные (интересные, но бесполезные или немонетизируемые) идеи, потому что:
1. такая работа будет держать команду в тонусе
2. бесполезная идея тоже может выстрелить
3. достижение любой цели, даже бесполезной, демонстрирует силу и способности, что может заинтересовать потенциального заказчика и побудить его сделать заказ более полезного проекта.
4. будет создавать фреймворк на котором другие подобные проекты будут писаться быстрее
5. будут налаживаться командные связи.
п4. немного спорный
Я делал свой фреймворк очень долго, сейчас пришёл к выводу, что лучше делать фреймворк по мере реализации других конкретных проектов. Иначе есть очень большой риск того, что ты сделаешь «крутой» фреймворк, который будет просто невозможно использовать для реальных задач.
Например, если речь идет о веб-разработке, то нужно поставить цель — сделать такой-то сайт или социальную сеть и в процессе работы над ними будут всплывать идеи как лучше сделать фреймворк.
То есть, я хочу, сказать, что первична задача, а не фреймворк, т.к. любой фреймворк делается быстрого решения задач определённого круга. Я очень сомневаюсь в возможности написания универсального фреймворка, который будет подходить под все задачи — он будет либо большим и неуклюжим монстром (и тогда он потеряет все свои плюсы), либо всё равно окажется ограниченным, в худшем случае вообще не пригодным.
Если изначально ставиться задача, а под неё пишется фреймворк, то есть гарантия, что фреймворк можно будет использовать для других таких же задач, и в дополнение возможно для других.
это тоже верно, для всех проектов один фреймворк точно не подойдёт.
Имхо, в такой ситуации, мне кажеться нужно прямо сейчас начать делать один проект. Будь то веб-проект или приложение какое-нибудь — вы сразу поймете, во что выльется вся задумка.
Выберите одну идею. Соберите команду для ее реализации, с оговоркой «получиться это, будем развиваться дальше» и вперед. Вот и будет вам Команда, Опыт, Портфолио.
Ответ тут: http://startuppoint.ru/blog/soft-com/1350.html