Pull to refresh

Comments 23

UFO landed and left these words here
Покажите мне тот учебник, я буду давать на него ссылку вместо того, чтобы писать лонгриды.
Любая книга др. Деминга
— Выход из крисиза
— DAO Toyota
и т.д.
Много лет они актуальны, ни один отдел по ним был построен.
Упоминаемый в статье Брукс актуален уже несколько десятилетий. Но почему-то каждый год я вижу новые и новые повторения одних тех же ошибок со все теми же печальными последствиями. Ну не читали люди, у которых есть идея и деньги, но которые раньше к разработке не имели отношения, ни Деминга, ни Брукса.

Весь смысл этой длинной статьи в том, чтобы на абсолютно реальных и довольно болезненных примерах обратить внимание то, что к работе с командой нужно подходить ответственно. И теорию — изучать.
Вот в отличии от учебников — в этой статье сильно чувствуется опыт. То ли потому что это распространенные практики, то ли еще почему то. как то так)
UFO landed and left these words here
Представьте себе человека, который состоялся и заработал деньги, скажем, в ресторанном бизнесе. А там заметно другие подходы к подбору и мотивации персонала. Это тоже сложная задача (поэтому рестораны так различаются по качеству обслуживания) и он умеет ее решать.

А теперь у этого человека есть идея сделать программный продукт. Только он не просто не читал этих учебников, он совершенно уверен, что ему их читать не нужно, он же умеет управлять персоналом! И вот он нанимает команду, вкладывает деньги, забирает с рынка специалистов и… всё это тратится с нулевым выхлопом. В процессе страдает основатель, страдает команда.

Цель, которую я ставил перед собой — не открыть миру новое знание, а изложить самые базовые моменты так, чтобы они были понятны человеку без опыта в индустрии, и при этом не вызывали совсем уж яростной критики тех, кто в теме.
UFO landed and left these words here
У меня и у нескольких рецензентов этой статьи ушло довольно много времени на то, чтобы ее подготовить. А люблю писать код и очень не люблю писать тексты. Поэтому мне ооочень не хочется писать вторую часть, где я обещал описать организацию работы команды.

Буду очень признателен, если вы припомните среди этого шлака и подкинете мне хорошую практическую статью в формате риск — как сделать правило/неправильно — цена ошибки. Я тогда дам ссылку на нее вместо обещанного продолжения.

Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.

А после майских праздников в этом году попросту выключился, бросив на произвол судьбы своих пользователей, и продукт, который мы делали. Это тоже результат описанных выше ошибок и один из основных поводов к написанию статьи.
Лучший способ что-то понять — попытаться объяснить это другому…
Угу, а объяснил пять раз — напиши уже статью на Мегамозг Хабр)
UFO landed and left these words here
Описание моего позитивного опыта построения команды не решит задачи, которая стоит перед статьей. Это как раз будет еще одна плюха в терриконах шлака, которая никому не интересна :)

Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.

В том случае, когда мне удалось собрать и поддерживать крутую команду, мне как раз удалось донести до основателей правильный подход. В других случаях не не брался за эту работу. Мой опыт донесения таких мыслей и собран в этой статье :)
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Да, так и есть. Статья для людей, которые пришли в IT делать бизнес и со всеми особенностями отрасли не знакомы. ДеМарко я тоже настойчиво рекомендовал к прочтению, вместе с Бруксом. Даже в свое время хотел купить десяток Peopleware в мягкой обложке и раздавать в подарок, но они тогда пропали из магазинов почему-то :)

Про квалификацию бред какой-то. Зачем описывать крайние случаи, если таковых не встречается? "Никакая квалификация, но зашкаливающая мотивация." — ни слова о том что чувак изговнокодит весь проект.


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

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

Описанные крайние случаи иногда вполне себе встречаются, по крайней мере, я все четыре случая видел лично. Но вы правы в том, что обычно обходится без крайностей.

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

Так вот нет, ошибки исправляются, а вот кашархитектура требуют переписывания компонента. Или чаще все забивают и на такой архитектуре пытаются что-то сделать. Это нельзхя назвать "выстрелит потом"


советы не такие уж очевидные,

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


Всем давно известны перечисляемые автором прицнипы: открытость, щедрость, прописанность всего и вся и прочее, однако ж на щедрость нехватает денег, на открытость — духа и планирования, на прописанность — представления и времени.

Only those users with full accounts are able to leave comments. Log in, please.