Статья: Правила Ашманова

<p align="right"><a href="http://www.ashmanov.com/" target="_blank"><b>Игорь Ашманов</b></a></p>

Данный свод высказываний предназначен для руководителей, которым
волей судеб пришлось заниматься новым для себя делом - управлять тем или иным
"программистским" проектом (созданием информационной системы предприятия,
разработкой сайта, и т. п.).

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

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

Много раз видели мы срыв сроков, провал проектов. Видели
бизнесменов, с готовностью вкладывавших деньги в новую технологию, поражающую
воображение - без понимания рынка, бизнес-планов и даже примерных результатов
и сроков работ. Я и сам совершал множество подобных ошибок за 15 лет работы
в индустрии производства программного обеспечения.

Вот эти простейшие вещи и собраны здесь в виде свода правил.
Вот самое первое из них:

Первое правило Ашманова. Не бывает технических проблем. Бывают
только человеческие, то есть организационные.

Я не даю здесь технических советов относительно управления
проектами, правил планирования и документирования, процедур тестирования
и выпуска. Обо всем этом написаны горы специальной литературы, в том числе
классическая книга Фредерика Брукса "Мифический человеко-месяц".

Однако должностные инструкции и правильные процедуры -
далеко не всё. При запуске проекта руководитель в первую очередь вступает в
человеческие отношения с коллегами, исполнителями, подчиненными.
Эти отношения сложны, непривычны и часто могут просто поставить в тупик,
если не знать всего нескольких простых правил.

Об управлении программистами

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

Управление программистами - не магия. Управлять
программным проектом может даже гуманитарий. Но для этого обязательно нужно
вообще уметь управлять людьми и проектами. Как и в любой отрасли, менеджеру
достаточно знать некоторые особенности технологического процесса и не
поддаваться "мифам индустрии". Всё остальное зависит от обычного умения
менеджера наладить работу.

Мифы. Управление программистами имеет особенности,
осложненные мифами и иллюзиями вокруг программирования. Эти мифы охотно
поддерживаются разработчиками и продавцами компьютерных услуг.


Читать всю статью: http://www.klerk.ru/soft/all?2123

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

Цитата:

---

Только программисты у меня неуправляемые

---

Так может это Вы ими управлять неумееете?

Конечно, не умею!
Гении вообще неуправляемые :)

Мнение простое.
Эта статья напоминает воспоминание человека, который что-то хотел автоматизировать, но что он хотел так никто и не понял. Он сам тоже.
Любым процессом нужно (и можно) управлять.
Но при этом должна быть четко сформулированная цель и желание высшего менеджмента использовать результаты этого процесса.
При этом оба условия равнозначны.
*

Lavrik, первые 3-4 главы Фредерика Брукса "Мифический человеко-месяц" позволят перестать бояться фразы "управление гениями" :) *в конкретной программистской реализации*

ОлегЪ, ага. У меня это настольная книга была :).

ОлегЪ, спасибо за совет. Век живи, век учись :)

ОлегЪ , вы похоже плохо читали книгу. ;) Там как раз говорится про то, что управление подобными проектами дело не простое, а реальные предложения появляются в 5 главе. А в последней, изданной в 20-м издании есть два очень интресных вывода:
Первое - за 20 лет по прежнему ничего не изменилось, а второй это то, что покупать коробочные продукты дешевле. (Но Брукс не знаком с 1С ;) )
Lavrik , кстати очень рекомендую эту книгу всем руководителям проектов, но только программных. А ещё осмелюсь напомнить знаменитую крылатую фразу Жванецкго: "Ты сначала придумай чего и сколько я должен зделать, а потом и требуй это сделать" (вольная трактовка). Т.е. каждый участник проекта должен знать "чего и сколько", т.е. надо придумать систему измерения трудозатрат, а это ох как не просто!!!

Dracosha Andrew, похоже, не один я надеюсь на память ;)
Впрочем, не собираюсь спорить по непринципиальным вопросам.

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

Замечание: Уже в очерке 86-го года был целый раздел "Покупать, а не создавать".

Еще одно замечание: 1С, несомненно, продукт. Несомненно, коробочный. Но не бухгалтерский (управленческий и пр.). Каждому овощу - свою сковородку :)

С уважением.

ОлегЪ
Согласен по всем вопросам.

На самом деле 2-й пункт у Брукса в дополнительной главе гласит, что единственное что появилось за 20 нового это ООП (специально вчера поглядел ;) , был не прав.)

Dracosha Andrew ;)

Надо бы в следующее посещение Питера сдвинуть кружки :)

Аплодирую статье! Очень понравилось. Действительно аплодирую, хоть и не без подвоха ;-) Аплодирую... В первую очередь смелости автора во фразе "гуманитарию управлять проектом" :-)
Не то чтобы я был слишком уж против... Может и кухарка управлять страной
Но все-таки давайте не будем забывать, что раз программист это инженер, то давайте оставим гуманитарию его гуманные задачи, а на его место поставим технологов, конструкторов и архитекторов, как это и положено :) И тогда во всем у нас будет порядок - отвечать за проект перед бизнесменами (менеджерами) будет соответствующим образом обученный и подготовленный менеджер - руководитель проекта, следить за балансом "общности" и "конкретности" будет архитектор (проектировщик), контролировать возможности платформы и особенность технических решений будет технолог (ведущий программист), ставить задачи будет конструктор (бизнес-аналитик), а внедрять систему будет специалист по внедрению и сопровождению. А программист будет заниматься лишь тем, чем ему и хочется - решать технические проблемы кодирования аналитических и проектных идей и отладкой соответствующей программы.

Да, еще. Если уж говорить о маркетологах и программистах ;-)
Лучше, если они не знают друг о друге. Тогда можно надеяться на то, что бизнес-аналитик (конструктор или менеджер продукта) выполняет свою работу как следует.
И еще, в защиту 1С :-) Я понимаю, что речь шла о типовых. В то же время, как я понимаю, вопрос возник от того, что у народа работают собственные 1С программисты. Я не знаю, откуда это взялось - найти себе гения "шнеца-жнеца-инадудеигреца", а потом пытаться делать вид, что есть проект и им нужно управлять, но как-то странно слышать от многих руководителей "мне бизнес-аналитик не нужен, я сам задачу поставлю". Дело конечно хозяйское... Даже метафору яркую привести сходу не могу. Ну, например, что бы вы сказали о президенте крупной компании, решающем, какую коробку на складе положить поближе к выходу, а какую подальше к стене? Любят, ой любят наши топ-менеджеры в игрушки играться. Ну, дай бог, повзрослеют. Мне в последнее время как-то везет. Встречаюсь в основном с людьми зрелыми и понимающими, что бизнес-аналитик это такая работа. Без которой говорить о проектировании системы не то чтобы нельзя... просто не стоит такую русскую забаву "а моя жаба краше" называть проектированием информационной системы :-) Ох, и чего это я так? Хозяин - барин. Чего велит, того ему и подать. Сам такой по жизни. И как отвыкнуть от привычки не лезть везде своим высокозадраннымотосознаниясобственнойинтеллектуальнойисключительности носом?

Хорошая статья. Я, как программист, согласен практически со всем, кроме правила 7 - таких программистов я практически не видел. А в остальном все актуально и истенно. У нас у самих менеджмента практически нет, что весьма сказывается на производительности. И менеджера хотелось бы иметь именно с такими принципами, какие здесь изложенны.

Цитата:

---

Надо бы в следующее посещение Питера сдвинуть кружки

---

Это никогда не поздно. Мой мобильный 8-921-752-4106

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