Скучающая истина

Факт: большинство проектов, которые я довел до конца, и которые принесли мне хоть какое-то удовлетворение, были сделаны либо в одиночку, либо с небольшим количеством подходящих людей.

Под подходящими людьми имеются ввиду люди, которые:
а) Имеют сильное желание заниматься этим проектом.
б) Разделяют мое видение проекта хотя бы на 70%.
в) Имеют аналогичные требования к уровню качества.
г) Превосходят меня по скиллам хотя бы в некоторых областях.
д) Могут делать то, за что взялись, в срок и без пинков.
е) Не напрягают, приятны для долговременной работы.

Выводы:
1) Команда должна состоять только из подходящих людей.
2) Команда должна быть минимальна. В идеале состоять из одного меня. Только когда команда не способна выдавать качественный результат в какой-то области, и это невозможно решить внутри команды или аутсорсом, может быть взят дополнительный подходящий человек. Ни в коем случае нельзя брать в команду неподходящего человека, даже при крайней необходимости (заменять аутсорсом).
3) Если что-то можно отдать в аутсорс и получить требуемый уровень качества быстрее и дешевле, чем силами команды, нужно это сделать. Но ни в коем случае нельзя аутсорсить то, что в аутсорсинге не может быть сделано достаточно хорошо. И всякий аутсорс должен постоянно контролироваться.
4) Каждый член команды должен четко отвечать за какое-то направление. Размытие ответственности недопустимо.
5) Доходы каждого члена команды должны быть пропорциональны его достижениям.

Проекты
Факт: абсолютно все проекты, которые были мне не интересны, либо были слишком велики для того, чтобы сделать их силами только подходящих людей, были завалены.

Выводы:
1) Не начинать проект если для него нет всех необходимых подходящих людей.
2) Не начинать проекты в не очень интересных мне предметных областях.
3) Не начинать (или хотя бы разбивать) слишком большие проекты (если за 80 чистых часов нельзя сделать прототип, проект -- большой).
4) Если на данный момент нет стабильного дохода, то делать проекты с пусть не самой большой, но понятной и быстрой монетизацией.
5) Избегать проектов, которые требуют большого количества оффлайна, сильно к чему-то привязывают.

Сроки
Факт: проекты с неизбежными дедлайнами гораздо чаще доводятся до конца.

Выводы:
1) Иметь дедлайны на версии и итерации. Стараться, чтобы они были завязаны на какие-то внешние события, чтобы их было сложно или невозможно передвинуть.
2) Снизить количество самоотмазок, запретив прощать себе проебы. Установить ежедневное чистое время работы над проектом (например 4 часа). Переносить все недоработанное время на следующий день и обязательно дорабатывать. Стараться выполнить все задачи итерации, даже если это ведет к превышению ежедневного времени (но не более, чем в два раза).
3) Однако помнить о том, что люди не роботы. Если работа перестала приносить удовольствие, необходимо пересмотреть планы, известить команду и отдохнуть (а не по тихому забивать, накапливая долги и снижая самооценку).

Знания и технологии
Факт: большинство проектов в которых я пытался применить новые, малознакомые технологии, были сильно задержаны, либо и вовсе провалены.

Выводы:
1) Спрашивать себя, какое действительно серьезное и необходимое улучшение может дать эта новая технология? Если ответ не сильно внятный -- не использовать ее.
2) Использовать только легковесные внешние решения. По возможности стараться обходиться только своим кодом, но не изобретать велосипед, если достойная легковесная реализация уже есть на рынке.
3) Понять, что я никогда не буду доволен уровнем своих знаний и сосредоточиться на работе на результат, а не чистом познании. Львиная доля знаний добавится в процессе работы.
4) Устранить большинство хронофагов и заменить их на чистое познание. В первую очередь стоит сосредоточиться на более глубоком изучении вещей, используемых в работе на результат (чтение полных мануалов, статей по новым подходам etc).

Инвестиции
Факт: брать инвестиции на ранних этапах сложно и не ведет ни к чему хорошему.

Выводы:
1) По возможности обходиться бутстрепом.
2) Если проект действительно пошел, лучше взять кредит и продать машину, чем привлекать инвесторов.
3) Брать внешние деньги только когда своих капиталлов уже совсем не хватает и есть четкое понимание на что эти деньги нужны. Ни в коем случае не отдавать большую долю (тем более контрольную).

Антиэнтропия
Факт: со временем в любом проекте все равно становится слишком много людей, технологий, документов etc.

Выводы:
1) Ввести четкий контроль за тем, что реально необходимо проекту, а что уже нет. В цифрах.
2) Избавляться от всего ненужного: людей (не забыв поблагодарить за былой вклад), оборудования, кода. технологий, документов etc.
3) Стараться не создавать ситуаций, когда избавиться от чего-то станет затруднительно.
4) В жопу шик, понты, ultimate, enterprise и corporate. Чем проще, тем лучше.
5) Заиметь человека, который, не будет стесняться указывать на вашу собственную энтропию и проебы.

Вкратце так. Если интересны подробности по каким-то конкретным пунктам -- в комменты.

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

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

3) Нужно иметь рядом людей, которые верят в тебя и твой проект. Не обязательно в команде, можно просто рядом. Нужно чтобы они трясли тебя: "Ну когда там уже?!". Так ты будешь понимать, что проект нужен не тебе одному и поторапливаться.