Хорошая практика, которой должен следовать каждый стартап [закрыто]

Несколько друзей на работе и я собираемся создать небольшой стартап / создать собственное программное обеспечение, вероятно, поначалу подрабатывающее луной, так как мы еще не можем позволить себе бросить нашу повседневную работу.

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

Для людей, которые пошли этим путем, какой совет (ы) вы бы дали нам?

Я больше ищу техническую сторону вещей, таких как:

• Стоит ли иметь какой-то сервер сборки или это будет далеко впереди?

• Вы бы сделали расширенный TDD или думаете, что это будет слишком много для небольшой команды, которая не слишком опытна в этом?

Но не прочь выслушать управленческую сторону вещей.

Проект представляет собой веб-приложение, выполненное в ASP.NET MVC, я думаю об использовании Mercurial и BitBucket или Kiln + FogBugz или какого-либо другого онлайн-инструмента отслеживания проектов, поскольку мы собираемся работать удаленно.

1. Выпустите как можно быстрее . Скорее всего, 90% кода, с которого вы начинаете, не дойдут до конца первых 6 месяцев. Так что нет смысла проектировать его как сумасшедшего. Кодируйте как можно быстрее, чтобы выйти на рынок, а затем пусть ваши пользователи решат, как его развивать дальше. Если TDD работает быстрее, используйте TDD. В противном случае просто взломать его. Ранние пользователи довольно легко прощают несколько ошибок, когда ваш продукт находится в бета-версии.

2. Не тратьте время на то, чтобы быть системными администраторами. У вас есть правильная идея с размещенными платформами для отслеживания ошибок (например, FogBugz) и контроля версий. Используйте онлайн-хранилище документов, такое как Google Docs . Если вы храните что-либо локально, используйте онлайн-сервис облачного резервного копирования, например, Carbonite . Если вы можете себе это позволить, арендуйте полностью управляемое решение для хостинга. Старайтесь избегать необходимости поддерживать свои собственные серверы.

3. Сконцентрируйтесь на том, что делает вас уникальным . Если вы обнаружите, что пишете код, который, кажется, должен был быть сделан раньше, используйте то, что уже есть. Станьте экспертами в решении вашей бизнес-проблемы и не отвлекайтесь на проблемы вне вашего домена.

если команда - это больше, чем вы, стандарты имеют значение. Они не должны быть сложными («используйте значимые имена переменных, CamelCase и не нарушайте сборку»). TDD качается, потому что он работает, используйте его. Тесты, которые вы придумали, также являются отличной основой для демонстраций. Сервер сборки может быть за бортом, а может и нет; начать без одного и посмотреть, как это идет. Инструменты отслеживания также; могу добавить позже по мере необходимости.

Предполагая , что этот продукт должны быть продано, сделать некоторые исследования рынка в настоящее время , чтобы убедиться , что вы строите то , что люди на самом деле хотят. Обрисуйте бизнес-план, чтобы перейти от нуля к рынку, разделить обязанности и справедливость и привлечь друг друга к ответственности.

Удачи!