Проект, как много в этом звуке
Originally posted by so_wa at Проект, как много в этом звуке
Было гладко на бумаге,
да забыли про овраги (с) Народный фольклор
В любом проекте, каким бы сказочным его ни рисовали в документации, всегда есть сакраментальная ложка-дегтя-в-бочке-меда и палка-в-колесе, мешающая сделать максимально красиво. И называется эта неприятность (нет, не угадали) "человеческий фактор". Как известно, у каждого хомо сапиенс есть свои представления о прекрасном и правильном с четким пониманием, сколько орехов - куча и что такое приемлемое качество работы. И чем больше людей работает над проектом, тем больше этих представлений варится в общем котле. Отдельно осложняет ситуацию разница между тем, как люди говорят о работе и как работают на самом деле. При том, что сами они этой разницы могут и не замечать. Да и не факт, что это вообще удастся объяснить им словами через рот. И не потому что они какие-то особенно неумные или злонамеренные. А потому что это нормально. Почему люди думают, что их сознание, мышление и контроль всеобъемлющи - об этом в другой раз. А сегодня про проекты.
Человеческий фактор -это еще не вся печаль. Каждый проект с самого начала и до наших дней всегда (!) будто нарочно строится по одной схеме, плюс-минус метр:
Схему эту чуть более ста лет назад описал и оформил в теорию товарищ Генри Гант. В результате получилась вот такая картиночка, как выше. Называется это каскадной моделью: очень много изначального планирования с большой кучей подробностей - сколько времени должно отводиться на каждый этап, как этапы перетекают один в другой и что должно получится в итоге именно по результатам всей этой бурной деятельности. Количество бардака увеличивается прямо пропорционально масштабу проекта. И уже к этапу апробации с диагностикой очень часто возникают вопросы из серии "а зачем в такой глубокой яме такой большой фонарь на дне?" Вот тут и выясняется, что хотели маяк, а получили колодец с мощной подсветкой. И хорошо, если выясняют это до сдачи проекта в эксплуатацию. Ситуация очень часто максимально осложняется тем, что заказчик бывает абсолютно не в курсе, как должен выглядеть итоговый продукт, а просто хочет "чтоб все было зашибись". И он старательно оформляет свое "зашибись" в техзадание (если он, конечно, молодец, а не как всегда). Как умеет, так и оформляет. У проекта часто есть руководитель, задача которого - сделать красиво и не свихнуться в процессе. И если он будет использовать каскадную модель планирования, то он, разумеется, представит клиенту шикарную картинку с цветными графиками в самом начале и что получится - в конце. На этом, собственно говоря, и появились кризис-менеджеры как явление - должен же кто-то тащить из болота того бегемота, читай - компанию, когда он там окончательно увязнет. И да, это частично помогает - кем-то извне натыкать мордочкой руководителя и исполнителей в том числе в то, что пока они там красиво планировали и не менее красиво исполняли, снаружи поменялись некоторые обстоятельства, но все были слишком заняты, чтобы это учесть.
И даже иногда появляются такие люди, как Джефф Сазерленд, которые говорят: "Люди, а давайте сменим методику!"
И добавляют что-то вроде этого:
Когда бы ни был запущен проект, вам ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляетесь ли вы с заданием; в нужном ли направлении движетесь; создаете ли именно то, что на самом деле хочет получить заказчик. Вам также ничто не мешает постоянно поднимать следующие вопросы: есть ли способы усовершенствовать методы разработки и выполнять работу наиболее качественно и быстро; существуют ли факторы, препятствующие вашим задачам. Процесс, описанный мною, назван «проверять и адаптироваться». Иначе говоря, в любой подходящий момент и как можно чаще следует прерывать сиюминутную работу, пересматривать то, что уже создано, и выяснять, все ли сделано, что нужно, и как это выполнить лучше. Мысль крайне простая, но ее воплощение потребует от вас внимательности, самоанализа, честности и дисциплины.
Хорошо, конечно. Симпатично. Особенно про честность и дисциплину. Я сама люблю нестандартные методики, особенно те, которые предполагают активное использование головы. Но. Человеческий фактор все еще никто не отменял. Что такое "справляться с заданием"? Где это - "нужное направление"? Какое именно "зашибись" из всех возможных вариантов "хочет получить заказчик"? И действительно ли то, что он "хочет" совпадает с тем, что на самом деле планирует получить (да, есть разница)?
Умение ответить на эти вопросы отличает просто руководителя проекта от очень хорошего руководителя проекта. Да, кстати. Не только это умение. Но и знание, что что-нибудь обязательно пойдет не так. И что все, в том числе он сам, способны в любой момент интерпретировать факты согласно своему личному сценарию и картине мира в голове. И качество итогового продукта идеальным не будет никогда. Однако, кто мешал просто сделать достаточно хорошо?
Что может помочь приблизиться к этому "достаточно хорошо"?
- Вытрясти из заказчика максимально подробное описание его "зашибись". Подробно его измерить. Задокументировать.
- Планировать. Планировать это полезно. Слепо следовать плану - глупо.
- Строить процесс вокруг практики, а не теории (то есть, согласно тому, как люди работают, а не как это описывают).
- Регулярно сверяться с заоконьем, не поменялось ли там чего принципиально важного.
- Смириться с мыслью о необходимости корректировок и перестать их бояться.
- Понять, что ошибка - не конец света, но чем раньше ее удастся поймать и устранить, тем лучше.
- Не пытаться сделать идеально, требование воплощения в жизнь идеала - это невроз, с ним - к врачу.
- Иметь инструкцию так, чтобы она не имела вас.
Как именно все это реализовать - зависит от того, какая у вас мышь что у вас за проект, кто заказчик, кто потребитель, где все живут и даже - каково содержание социально-культурных паттернов поведения, статистически нормальных для данной местности.
Удачи, товарищи.
Было гладко на бумаге,
да забыли про овраги (с) Народный фольклор
В любом проекте, каким бы сказочным его ни рисовали в документации, всегда есть сакраментальная ложка-дегтя-в-бочке-меда и палка-в-колесе, мешающая сделать максимально красиво. И называется эта неприятность (нет, не угадали) "человеческий фактор". Как известно, у каждого хомо сапиенс есть свои представления о прекрасном и правильном с четким пониманием, сколько орехов - куча и что такое приемлемое качество работы. И чем больше людей работает над проектом, тем больше этих представлений варится в общем котле. Отдельно осложняет ситуацию разница между тем, как люди говорят о работе и как работают на самом деле. При том, что сами они этой разницы могут и не замечать. Да и не факт, что это вообще удастся объяснить им словами через рот. И не потому что они какие-то особенно неумные или злонамеренные. А потому что это нормально. Почему люди думают, что их сознание, мышление и контроль всеобъемлющи - об этом в другой раз. А сегодня про проекты.
Человеческий фактор -это еще не вся печаль. Каждый проект с самого начала и до наших дней всегда (!) будто нарочно строится по одной схеме, плюс-минус метр:
Схему эту чуть более ста лет назад описал и оформил в теорию товарищ Генри Гант. В результате получилась вот такая картиночка, как выше. Называется это каскадной моделью: очень много изначального планирования с большой кучей подробностей - сколько времени должно отводиться на каждый этап, как этапы перетекают один в другой и что должно получится в итоге именно по результатам всей этой бурной деятельности. Количество бардака увеличивается прямо пропорционально масштабу проекта. И уже к этапу апробации с диагностикой очень часто возникают вопросы из серии "а зачем в такой глубокой яме такой большой фонарь на дне?" Вот тут и выясняется, что хотели маяк, а получили колодец с мощной подсветкой. И хорошо, если выясняют это до сдачи проекта в эксплуатацию. Ситуация очень часто максимально осложняется тем, что заказчик бывает абсолютно не в курсе, как должен выглядеть итоговый продукт, а просто хочет "чтоб все было зашибись". И он старательно оформляет свое "зашибись" в техзадание (если он, конечно, молодец, а не как всегда). Как умеет, так и оформляет. У проекта часто есть руководитель, задача которого - сделать красиво и не свихнуться в процессе. И если он будет использовать каскадную модель планирования, то он, разумеется, представит клиенту шикарную картинку с цветными графиками в самом начале и что получится - в конце. На этом, собственно говоря, и появились кризис-менеджеры как явление - должен же кто-то тащить из болота того бегемота, читай - компанию, когда он там окончательно увязнет. И да, это частично помогает - кем-то извне натыкать мордочкой руководителя и исполнителей в том числе в то, что пока они там красиво планировали и не менее красиво исполняли, снаружи поменялись некоторые обстоятельства, но все были слишком заняты, чтобы это учесть.
И даже иногда появляются такие люди, как Джефф Сазерленд, которые говорят: "Люди, а давайте сменим методику!"
И добавляют что-то вроде этого:
Когда бы ни был запущен проект, вам ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляетесь ли вы с заданием; в нужном ли направлении движетесь; создаете ли именно то, что на самом деле хочет получить заказчик. Вам также ничто не мешает постоянно поднимать следующие вопросы: есть ли способы усовершенствовать методы разработки и выполнять работу наиболее качественно и быстро; существуют ли факторы, препятствующие вашим задачам. Процесс, описанный мною, назван «проверять и адаптироваться». Иначе говоря, в любой подходящий момент и как можно чаще следует прерывать сиюминутную работу, пересматривать то, что уже создано, и выяснять, все ли сделано, что нужно, и как это выполнить лучше. Мысль крайне простая, но ее воплощение потребует от вас внимательности, самоанализа, честности и дисциплины.
Хорошо, конечно. Симпатично. Особенно про честность и дисциплину. Я сама люблю нестандартные методики, особенно те, которые предполагают активное использование головы. Но. Человеческий фактор все еще никто не отменял. Что такое "справляться с заданием"? Где это - "нужное направление"? Какое именно "зашибись" из всех возможных вариантов "хочет получить заказчик"? И действительно ли то, что он "хочет" совпадает с тем, что на самом деле планирует получить (да, есть разница)?
Умение ответить на эти вопросы отличает просто руководителя проекта от очень хорошего руководителя проекта. Да, кстати. Не только это умение. Но и знание, что что-нибудь обязательно пойдет не так. И что все, в том числе он сам, способны в любой момент интерпретировать факты согласно своему личному сценарию и картине мира в голове. И качество итогового продукта идеальным не будет никогда. Однако, кто мешал просто сделать достаточно хорошо?
Что может помочь приблизиться к этому "достаточно хорошо"?
- Вытрясти из заказчика максимально подробное описание его "зашибись". Подробно его измерить. Задокументировать.
- Планировать. Планировать это полезно. Слепо следовать плану - глупо.
- Строить процесс вокруг практики, а не теории (то есть, согласно тому, как люди работают, а не как это описывают).
- Регулярно сверяться с заоконьем, не поменялось ли там чего принципиально важного.
- Смириться с мыслью о необходимости корректировок и перестать их бояться.
- Понять, что ошибка - не конец света, но чем раньше ее удастся поймать и устранить, тем лучше.
- Не пытаться сделать идеально, требование воплощения в жизнь идеала - это невроз, с ним - к врачу.
- Иметь инструкцию так, чтобы она не имела вас.
Как именно все это реализовать - зависит от того, какая у вас мышь что у вас за проект, кто заказчик, кто потребитель, где все живут и даже - каково содержание социально-культурных паттернов поведения, статистически нормальных для данной местности.
Удачи, товарищи.