Gute Praktiken, die jedes Startup befolgen sollte [geschlossen]


9

Ein paar Freunde bei der Arbeit und ich werden ein kleines Startup einrichten / unsere eigene Software erstellen, wahrscheinlich zuerst im Mondlicht, da wir es uns noch nicht leisten können, unsere Tagesjobs zu kündigen.

Keiner von uns hat diese Erfahrung gemacht, wir haben alle zuvor für andere Unternehmen gearbeitet, in denen eine Reihe von Richtlinien festgelegt wurden, und ich denke, dies ist die Zeit, um bewährte Verfahren festzulegen (z. B. das Vermeiden von Besprechungen).

Welche Ratschläge würden Sie uns für Menschen geben, die diesen Weg gegangen sind?

Ich suche mehr nach der technischen Seite von Dingen, Dinge wie:

  • Lohnt es sich, eine Art Build-Server zu haben, oder geht das zu weit?

  • Würden Sie umfangreiche TDD durchführen oder denken Sie, dass dies für ein kleines Team, das nicht zu viel Erfahrung damit hat, zu viel Aufwand bedeutet?

Aber es würde nichts ausmachen, auf die Managementseite der Dinge zu hören.


Das Projekt ist eine Webanwendung, die in ASP.NET MVC erstellt wurde. Ich denke darüber nach, Mercurial und BitBucket oder Kiln + FogBugz oder ein anderes Online-Projektverfolgungstool zu verwenden, da wir remote arbeiten werden.


1
Ich habe mir erlaubt, Ihre Frage zu bearbeiten, um den 3Teil davon zu entfernen - es ist nicht nützlich / konstruktiv, eine willkürliche Grenze für die Anzahl der Dinge festzulegen, die die Leute vorschlagen sollten (und wahrscheinlich würden die meisten Leute das sowieso ignorieren).
Peter Boughton

Versuchen Sie, teddziuba.com/archives.html nicht zu scheitern. Normalerweise lernen Sie dies beim dritten Mal.
Job

Antworten:


15
  1. So schnell wie möglich loslassen . Es besteht die Möglichkeit, dass 90% des Codes, mit dem Sie beginnen, die ersten 6 Monate nicht überschreiten. Es macht also keinen Sinn, es wie verrückt zu konstruieren. Codieren Sie so schnell wie möglich, um auf den Markt zu kommen, und lassen Sie dann Ihre Benutzer entscheiden, wie sie ihn weiterentwickeln möchten. Wenn Sie mit TDD am schnellsten codieren, verwenden Sie TDD. Ansonsten hacke es einfach. Early-Adopter-Benutzer verzeihen einige Fehler, wenn sich Ihr Produkt in der Beta befindet.

  2. Verschwenden Sie keine Zeit damit, Systemadministratoren zu sein. Mit gehosteten Plattformen für Bug-Tracking (z. B. FogBugz) und Quellcodeverwaltung haben Sie die richtige Idee. Verwenden Sie ein Online-Dokumenten-Repository wie Google Text & Tabellen . Wenn Sie etwas lokal speichern, verwenden Sie einen Online-Cloud-Sicherungsdienst wie Carbonite . Mieten Sie in Ihrer Live-Umgebung eine vollständig verwaltete Hosting-Lösung, wenn Sie es sich leisten können. Versuchen Sie, keine eigenen Server warten zu müssen.

  3. Konzentrieren Sie sich auf das, was Sie einzigartig macht . Wenn Sie feststellen, dass Sie Code schreiben, der anscheinend schon einmal ausgeführt wurde, verwenden Sie den bereits vorhandenen Code. Werden Sie Experten bei der Lösung Ihres Geschäftsproblems und lassen Sie sich nicht von Problemen außerhalb Ihrer Domäne ablenken.


4

Wenn das Team mehr als nur Sie ist, sind Standards wichtig. Sie müssen nicht kompliziert sein ("Verwenden Sie aussagekräftige Variablennamen, CamelCase, und brechen Sie den Build nicht ab"). TDD rockt, weil es funktioniert, benutze es. Die Tests, die Sie erstellen, bilden auch eine hervorragende Grundlage für Demos im Handumdrehen. Ein Build-Server ist möglicherweise über Bord, möglicherweise nicht. Beginnen Sie ohne und sehen Sie, wie es geht. Tracking-Tools ebenfalls; kann später nach Bedarf hinzugefügt werden.

Angenommen, dieses Produkt soll verkauft werden, führen Sie jetzt Marktforschungen durch , um sicherzustellen, dass Sie etwas bauen, das die Leute tatsächlich wollen. Skizzieren Sie einen Geschäftsplan, um von Null auf den Markt zu gelangen, Verantwortlichkeiten und Eigenkapital aufzuteilen und sich gegenseitig zur Rechenschaft zu ziehen.

Viel Glück!


Ja, es wäre eine abonnementbasierte Web-App. Wie würden Sie einen Geschäftsplan ohne Betriebswirtschaftslehre erstellen?
Francisco Noriega

@ Francisco kurze Antwort: lernen. Lange Antwort: Sie brauchen keinen MBA-Businessplan, aber Sie brauchen einen Plan, der die Grundlagen abdeckt: Was bauen Sie, für wen bauen Sie ihn, welche Konkurrenten gibt es, warum ist Ihr Widget speziell / anders, wie sind Sie werden es vermarkten / bewerben, wie lange jeder Schritt dauern wird, welche Ressourcen Sie zu welchem ​​Zeitpunkt benötigen, welches Umsatzniveau Sie benötigen, um die Gewinnschwelle zu erreichen und / oder Ihr unmittelbares finanzielles Ziel zu erreichen. An wen werden Sie es verkaufen und warum sollten sie sich darum kümmern? Mach das zuerst.
Steven A. Lowe

Vielen Dank für den soliden Rat! Ich glaube, ich kenne die Antwort auf viele davon bereits, aber nur in meinem Kopf und mit ein paar Leuten, mit denen ich gesprochen habe, ist es wahrscheinlich eine gute Idee, sie niederzulegen und mit mehr zu unterstützen Beweise .. nochmals vielen Dank!
Francisco Noriega
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.