Комментарии 24
— Выход из крисиза
— DAO Toyota
и т.д.
Много лет они актуальны, ни один отдел по ним был построен.
Весь смысл этой длинной статьи в том, чтобы на абсолютно реальных и довольно болезненных примерах обратить внимание то, что к работе с командой нужно подходить ответственно. И теорию — изучать.
А теперь у этого человека есть идея сделать программный продукт. Только он не просто не читал этих учебников, он совершенно уверен, что ему их читать не нужно, он же умеет управлять персоналом! И вот он нанимает команду, вкладывает деньги, забирает с рынка специалистов и… всё это тратится с нулевым выхлопом. В процессе страдает основатель, страдает команда.
Цель, которую я ставил перед собой — не открыть миру новое знание, а изложить самые базовые моменты так, чтобы они были понятны человеку без опыта в индустрии, и при этом не вызывали совсем уж яростной критики тех, кто в теме.
Буду очень признателен, если вы припомните среди этого шлака и подкинете мне хорошую практическую статью в формате риск — как сделать правило/неправильно — цена ошибки. Я тогда дам ссылку на нее вместо обещанного продолжения.
Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.
А после майских праздников в этом году попросту выключился, бросив на произвол судьбы своих пользователей, и продукт, который мы делали. Это тоже результат описанных выше ошибок и один из основных поводов к написанию статьи.
Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.
В том случае, когда мне удалось собрать и поддерживать крутую команду, мне как раз удалось донести до основателей правильный подход. В других случаях не не брался за эту работу. Мой опыт донесения таких мыслей и собран в этой статье :)
Про квалификацию бред какой-то. Зачем описывать крайние случаи, если таковых не встречается? "Никакая квалификация, но зашкаливающая мотивация." — ни слова о том что чувак изговнокодит весь проект.
Остальная статья в том же духе, поверхностный сборник очевидных советов из учебников.
Описанные крайние случаи иногда вполне себе встречаются, по крайней мере, я все четыре случая видел лично. Но вы правы в том, что обычно обходится без крайностей.
Ну а что касается очевидности… К сожалению, для людей, которые эти учебники не читали (а я несколько раз прямо в руки такой учебник выдавал, только на их прочтение всегда не хватало времени) — советы не такие уж очевидные, и часто противоречат накопленному опыту подбора людей и организации их работы.
Совершает всевозможные ошибки, часть из которых проявляется немедленно, а часть выстрелит потом.
Так вот нет, ошибки исправляются, а вот кашархитектура требуют переписывания компонента. Или чаще все забивают и на такой архитектуре пытаются что-то сделать. Это нельзхя назвать "выстрелит потом"
советы не такие уж очевидные,
Приведите примеры неочевидных. Пока вы их ищете, я скажу вот что:
Автор не понимает, что большинство делает неправильно не потому что не знает как делать хорошо, а по каким-то другим причинам. Дьявол в деталях и ресурсах.
Всем давно известны перечисляемые автором прицнипы: открытость, щедрость, прописанность всего и вся и прочее, однако ж на щедрость нехватает денег, на открытость — духа и планирования, на прописанность — представления и времени.
В шоке от комплексов по поводу больших компаний. И люди с такой позицией принимают решения о найме.
По личному опыту в двух больших компаниях, там 5% мотивированы на результат - работают ради опыта, который сами считают недостаточным и 95% - ориентированных на пассивное или активное паразитирование.
Как вариант, попадались спецы, знающие свой стек на отлично, только стек был уже умерший от старости.
Как набрать в IT-стартап команду разработки, которая действительно сделает продукт?