Почему в срок не изготовили – Конкретно почему не сделали — Coub

Конкретно почему не сделали — Coub

Конкретно почему не сделали — Coub — The Biggest Video Meme Platform

• Home
• Hot
• Random

• Show more…

  Show less

• My likes
• Bookmarks
• Communities

• Animals & Pets

• Mashup

• Anime

• Movies & TV

• Gaming

• Cartoons

• Art & Design

• Music

• News & Politics

• Sports

• Science & Technology

• Celebrity

• Nature & Travel

• Fashion & Beauty

• Dance

• Auto & Technique

• NSFW

• Featured

• Coub of the Day

coub.com

Почему в срок не изготовили? -Проспал! — Coub

Почему в срок не изготовили? -Проспал! — Coub — The Biggest Video Meme Platform

• Home
• Hot
• Random

• Show more…

  Show less

• My likes
• Bookmarks
• Communities

• Animals & Pets

• Mashup

• Anime

• Movies & TV

• Gaming

• Cartoons

• Art & Design

• Music

• News & Politics

• Sports

• Science & Technology

• Celebrity

• Nature & Travel

• Fashion & Beauty

• Dance

• Auto & Technique

• NSFW

• Featured

• Coub of the Day

coub.com

9 на 9. Почему срываются сроки проектов и как не срывать их

Почему при словах «мы начинаем новый проект» внутренний голос часто говорит: «и снова сорвем сроки»? Есть простое объяснение. Большинство проектов действительно срывают плановые сроки.

Фото с сайта deviantart.com

Посмотрите на эти таблицы.

Статистика успешности ИТ-проектов в мире

(с) The Standish Group. CHAOS MANIFESTO 2013

Сроки, бюджеты и реализация требований в категории «спорных» ИТ-проектов

(с) The Standish Group. CHAOS MANIFESTO 2013

Из 43% проектов, которые в 2012 году признали «спорными», проблемы со сроками испытали 74% проектов. Перемножив два числа, получаем, что в 32% от общего числа ИТ-проектов были сорваны сроки. Плюс еще 18% «провальных», в которых наверняка были проблемы со сроками. Получается, что в 50% случаев ИТ-проекты не завершаются в плановый срок.

Если верить этому исследованию, в России в 2007 году в срок выполнялось только 4% ИТ-проектов. Если бы подобная статистика была по ИТ-проектам в Беларуси, то, я уверен, она бы не сильно отличалась. И вряд ли ситуация радикально улучшилась за последние семь лет.

Что же происходит? Оказывается, у нас вообще плохо обстоит дело с прогнозами, особенно долгосрочными. Об этом пишут когнитивные психологи, например, Д.Канеман.

Проекты обычно длятся от полугода до нескольких десятилетий, и чем масштабнее с точки зрения трудоемкости проект, тем ниже вероятность, что мы угадаем фактический срок его реализации. Кроме плохих прогнозов мы еще часто игнорируем и давно проверенные инструменты «управления проектами», что усугубляет ситуацию.

Итак, каковы причины срыва сроков проектов? На мой взгляд, они следующие:

1. Неверная оценка проектов на старте

Для оценки проектов на старте можно использовать метод аналогов. Но в Беларуси есть проблема: никто не занимается сбором и публикацией статистики по реализованным проектам. Почему? Государственным органам это не нужно, а частные компании пока не понимают значимости такой статистики и, скорей всего, не готовы делиться достоверной информацией о выполненных проектах. А, представьте, как облегчилась бы участь руководителя проекта, если бы он имел возможность изучить опыт ста похожих проектов и узнать в какой диапазон по срокам и бюджету они уложились!

2. Большой размер проекта

Статистика The Standish Group явно демонстрирует нам зависимость успеха от масштаба проекта. Если намечается ИТ-мегапроект, я рекомендую разбить его на небольшие проекты и управлять ими как программой проектов. По небольшому проекту и прогноз сроков окажется более достоверным.

(с) The Standish Group. CHAOS MANIFESTO 2013

3. Неполные требования к продуктам проекта, что приводит к неполному списку работ

Я рекомендую выделить сбор и анализ требований к продуктам в отдельный проект. Не для всех проектов этот вариант будет верным (есть подходы к управлению проектами, которые рекомендуют сбор и анализ требований проводить параллельно с разработкой продукта). Понятно, что в процессе реализации требования могут измениться. Но если они были хорошо проработаны, то, скорее всего, изменятся на 10-20% по отношению к первоначальным, а не на 50-70%.

4. Руководители проектов часто не используют ресурсное планирование

Ресурсное планирование предполагает, что длительность задач в сетевом графике рассчитывается на основании трудозатрат по задаче, ресурсов, назначенных на задачу, и «% доступности» этих ресурсов. Зачастую руководители проектов даже не проверяют адекватность сроков работ в плане с учетом имеющихся ресурсов. По сути, они составляют график работ, исходя из предположения, что ресурсов будет достаточно для выполнения задач в плановый срок.

5. Слабое использование методов сетевого планирования

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

6. Изменения требований к продуктам проекта по ходу проекта

Понимая то, что требования по ходу реализации проекта будут меняться, руководителю проекта вместе с заказчиком следует выстроить процедуру ранжирования требований и определить, без каких из них продукт проекта невозможно будет использовать (must have), а какие являются желательными (nice to have). Если вдруг сроки будут затягиваться, команда проекта сможет подготовить работающий продукт, включающий ключевые требования, и передать его в эксплуатацию, а остальные требования (nice to have) можно реализовать на этапе промышленной эксплуатации продукта.

7. Слабое внимание управлению рисками

Дату завершения проекта, которая рассчитана без учета имеющихся в проекте рисков, называют «нанопроцентной датой». Потому что вероятность завершения проекта именно в эту дату составляет примерно один нанопроцент…

8. Недостаточный контроль над выполнением работ

Даже хороший план может привести к провалу, если не выстроена адекватная система контроля хода работ по проекту. Чаще всего руководители проекта получают информацию о ходе работ в виде отчета по статусам задач. Что-то типа:

0% – задача не начата

50% – в работе

100% – закончена

Мало того, информация о выполнении работ собирается не каждый день, а раз в неделю (или еще реже). Я считаю, что для большинства проектов такой уровень контроля недостаточен. Мне, как руководителю проекта, хочется каждый день иметь понимание, какой объем работ по проекту уже сделан, а какой еще остался. И делать прогнозы о завершении проекта в срок.

В управлении проектами уже давно существует методика контроля проекта, которая удовлетворяет моим требованиям – это методика освоенного объема. Правда, она предполагает использование «% физического выполнения объемов работ» либо «% завершения по трудозатратам» по каждой задаче проекта.

Приведу пример: задача запланирована на 10 человеко-часов. Исполнитель сегодня потратил на нее 6 человеко-часов, каков «% завершения задачи»?

Можно подумать, что задача завершена на 60% (6 часов из 10 уже потрачено), но что если это не так и исполнителю нужно еще 8 часов, чтобы получить результат по задаче?

В этом случае % завершения = 43% (6/(6+8) *100% = 43%).

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

Для использования этой методики нам придется внедрить в своем проекте отчеты о фактически потраченном и оставшемся времени по задачам. Это будет сделать непросто, но уж если мы это сделаем, то заодно решим проблему отсутствия статистики – у нас начнет накапливаться информация по фактическим трудозатратам в разрезе похожих работ.

9. Недостаточная вовлеченность заказчика проекта

Она проявляется в затягивании принятия решений по важным вопросам. В проекте приходится принимать тысячи решений, и, по мнению The Standish Group, в 20% случаев для принятия решений нам нужен заказчик проекта. И если решения будут приниматься дольше запланированных сроков, это, понятное дело, будет влиять на общий срок проекта.

Секреты выполнения проекта в срок

На мой взгляд, они следующие:

1. Оценка объемов работ на старте проекта методом аналогов.

2. Небольшой размер проекта.

3. Сбор и анализ требований до старта проекта, уточнение оценки объемов работ проекта на основании требований.

4. Использование ресурсного планирования.

5. Использование методов критического пути и критической цепочки для определения сроков проекта.

6. Управление приоритетами требований и изменениями требований по ходу проекта.

7. Пристальное внимание работе с рисками.

8. Контроль проекта с помощью метода освоенного объема.

9. Назначение в проект квалифицированного и мотивированного заказчика проекта (или его представителя).

Стоит прочесть:

• Лоуренс Лич, «Вовремя и в рамках бюджета: Управление проектами по методу критической цепи». Прекрасная книга, объясняющая все тонкости «метода критической цепи».
• Д.Канеман, «Думай медленно…решай быстро». Книга о том, как устроен наш мозг и как мы принимаем решения. Много интересной информации о наших стереотипах и ловушках мышления.
• Т. ДеМарко и Т. Листер, «Вальсируя с медведями». Пожалуй, лучшая книга на русском языке по управлению рисками в ИТ-проектах.

Удачи в управлении сроками!

Максим Якубович

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами – более 10 лет.  

20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.  

Опыт преподавания – 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.  

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.

probusiness.io

Почему бытовая техника стала быстрее ломаться?

По сей день в некоторых домах можно найти чудеса советской техники: по 25 лет тарахтят на кухнях ЗИЛы, с надрывом пылесосят ковры «Тайфуны» и все так же стирают без отжима «Вятки». Такую технику покупали на века, и она успешно, без серьезных поломок справляется с возложенными на нее обязанностями сегодня. А вот срок службы современных устройств часто вызывает немало вопросов у покупателей и мастеров по ремонту: мол, где же старые добрые приборы–долгожители и почему так короток век новеньких холодильников и «стиралок»? Пробуем разобраться.

Неужели производители, несмотря на шагающий семимильными шагами прогресс, разучились делать качественную и долгоживущую бытовую технику? Или нам целенаправленно всучивают одноразовый товар, намеренно укорачивая ему сроки службы? Вопрос весьма неоднозначный, считает ведущий инженер Белорусского государственного института стандартизации и сертификации Денис Савич:

— С одной стороны, редкий производитель пожертвует своей репутацией: такое осознанное пренебрежение качеством повлияет на имидж марки и объем продаж. Конкуренция все время вынуждает улучшать характеристики изделий, в том числе увеличивать и срок службы. Люди начинают обращать внимание на технические и другие параметры продукции. С другой стороны, некоторые изготовители действительно могут держаться на рынке за счет увеличения продаж более–менее низкого по цене и качеству товара по принципу «сломалось — выкинул — купил новое».

Можно сравнить современную компактную стиральную машину с ее советским «предком»: преимущества очевидны. Однако и материалы в них будут значительно отличаться: какие–то заменили более легкими и дешевыми (а следовательно, менее долговечными), корпус стал более презентабельным, но пластиковым. Даже самая незначительная экономия производителя на составляющих элементах прибора может сказаться на сроке службы всего механизма. Это, конечно, уменьшает себестоимость холодильника, но от снижения цены может пострадать и качество. Да и общество потребления, где культивируются материальные блага, диктует нам свои условия. Не всякий бытовой прибор доживает до «заслуженного отдыха» по той простой причине, что многие привыкли менять свои технические «игрушки»: стоит «стиралке», утюгу или холодильнику обзавестись новым наворотом, как он тут же оттесняет предшественника. А реклама такой подход поощряет и на каждом шагу призывает: «Налетай! Торопись! Покупай!»

(adsbygoogle = window.adsbygoogle || []).push({});

Штрихи к проблеме

Что такое гарантийный срок, знает каждый. Кстати, по статистике, подавляющее большинство товаров успешно и без нареканий со стороны покупателя его отрабатывает. Конечно, бывают исключения в виде заводского брака или других изначально скрытых недостатков. Именно в таких случаях эта самая гарантия и защищает нас от некачественных изделий. Гораздо сложнее обстоят дела с понятием «срок службы». Говоря простым языком, производитель в течение этого времени должен предоставить вам возможность пользоваться товаром. Что это значит? Если в руководстве по эксплуатации, скажем, холодильника обозначено, что он должен верой и правдой служить 10 лет, то весь этот период вам обязаны обеспечить возможность ремонта: ровно столько с момента выпуска последнего холодильника данной модели будут хранить или изготавливать запасные комплекты запчастей.

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

Конечно, срок службы напрямую зависит от правильной эксплуатации прибора. В большинстве случаев техника работает значительно дольше, нежели заявлено в инструкции, если вы обращаетесь с ней должным образом. В советские времена срок службы строго регламентировался: холодильники должны были отработать 15 лет, газовые плиты — 20, электроплиты — 16,5. Понятие «срок службы» у нас закреплено законодательно, однако по большей части отмеряют его сами изготовители после различных испытаний и исследований. Может, стоит вернуться к практике былых времен и четко обозначить время жизни для каждого прибора? Денис Савич считает, что с технической точки зрения это будет слабообоснованным решением:

— Заявленный срок службы является больше экономической характеристикой, а не технической, так как позволяет рассчитывать примерный срок эксплуатации изделия до замены. Изготовитель, определяя срок службы, исходит из своих условий, а реальные условия эксплуатации у потребителя могут быть другими. Например, у кого–то холодильник стоит на даче и включается всего на пару недель, а у кого–то все время работает в квартире. Стиральную машину, телевизор, микроволновку, электрический чайник могут использовать лишь несколько раз за неделю, а могут — без перерыва в каком–нибудь заведении. Какой прибор выйдет из строя раньше? Один производитель использует более дешевые материалы и комплектующие, срок службы его бытовой техники будет меньше, но и цена ниже. А другой выбирает качественные и дорогие составные части. Покупатель сам определяется с категорией товара. Поэтому устанавливать единый срок службы для всех будет неправильно: это скажется и на конкуренции, и на цене, и на возможности выбора бытовой техники. Но изготовитель должен указывать срок службы изделий, чтобы информировать потребителя.

Прислушиваться к производителям стоит, ведь подобные цифры в инструкциях по эксплуатации появляются отнюдь не просто так: устаревшая техника может стать причиной пожара. К примеру, очень строго регламентируются сроки службы газовых плит: 10 лет. В течение этого времени производитель еще будет выпускать запчасти к вашей модели. Однако срок можно официально продлить, если плита хорошо работает: сотрудники газовой службы проведут необходимую диагностику. А вот спустя 20 лет даже при условии своевременной диагностики и исправного состояния плиту все равно придется заменить.

Справка «СБ»

Сколько примерно может прослужить бытовая техника

Холодильник — 7 — 10 лет.

Стиральная машина — 7 — 8 лет.

Пылесос — 3 — 7 лет.

Микроволновка — 7 лет.

Посудомоечная машина — 5 лет.

Чайники, фены, мелкая бытовая техника — 3 года, профессиональная — 5 — 7 лет.

Ольга САВКО.

Заметили ошибку? Пожалуйста, выделите её и нажмите Ctrl+Enter

www.sb.by

Почему срок службы бытовой техники стал короче

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

Сегодня многие российские граждане помнят, сколько служили в былые времена, к примеру, стиральные машины. Первые ввезенные в Россию «стиралки» без серьезных поломок несли свой крест более пятнадцати — двадцати лет, пока хозяева не выносили их на свалку в связи с изношенностью. Кроме того, наши сограждане до сих пор с теплом в сердце вспоминают произведенные на советских заводах утюги, отдельные представители которых, быть может, до сих пор в отдаленных уголках России используются по назначению. Так почему современные бытовые приборы столь быстро выходят из строя? Разумеется, дело не в том, что производители техники неожиданно разучились собирать долгоиграющую технику.

Существует версия, которая очень близка приверженцам теории вселенского заговора, согласно которой производители при сборке техники заранее программируют ее на поломку. Причем, чем раньше произойдет эта поломка, тем скорее покупатель вынужден будет купить новый бытовой прибор. Логика очевидна — если вся бытовая техника будет работать десятилетиями, то игроки этой рыночной отрасли останутся без постоянной прибыли, и в результате зачахнут от скуки. Разумеется, технические новинки и разработки будут привлекать отдельных представителей общества в магазины бытовой техники, однако та часть человечества, которая надежность ценит больше технических новшеств, или же просто не может похвастаться большими финансовыми возможностями, будет безвозвратно утеряна для производителей. Если же бытовые приборы будут ломаться часто… Суть сей теории кроется в том, что современное гражданское общество деятели рынка постепенно превращают в то самое «общество потребления». И, надо заметить, превращают успешно.

Но есть здесь и серьезное противоречие. Ведь рынок бытовой техники, как и любой другой, не может существовать без конкуренции. А одним из главных гарантов качества бытовых приборов является именно продолжительный срок службы. С упором на этот пункт, например, делает рекламу своей продукции компания Indesit, маркетологи которой избрали громкий лозунг «Индезит — прослужит долго!». Как же деятели этой отрасли могут создавать недолговечную технику, при этом оставаясь конкурентоспособными и востребованными? И есть ли хоть доля истины в теории запрограммированной поломки? С этим вопросом редакция Правда. ру обратилась к экспертам.

Читайте также: На крючке у общества потребления

«Я думаю, что это всего лишь версия, абсолютно ничем не подтвержденная, — поделился мнением юрист «Общества защиты прав потребителей» Игорь Зверев, — Никто специально не будет изготавливать товары скоропортящиеся, ломающиеся, с маленьким сроком годности. Продавцу не выгодно это. Наоборот, ему требования будут предъявлять, если вдруг он продаст некачественный товар, ему придется нести свои затраты — менять, возвращать товар. Это просто чей-то домысел».

С господином Зверевым согласна и эксперт потребительского рынка Марина Петрухина. «Тут чисто теоретически сложно сказать, что существует такое пренебрежение качеством. Я не очень верю, потому что пренебрежение качеством влияет на развитие марки. То есть если ты однажды сделал под уже известным брендом некачественный продукт, то к бренду доверие теряется у потребителя. В маркетинге все более сложно ранжируется, — объяснила корреспонденту Правды. Ру Марина Петрухина, — Производитель, например, может делать более дешевые вещи, но здесь стоит вопрос цены. Есть более дешевые вещи, где используются пластмассовые детали, которые быстрее выходят из строя, чем металлические. А вещь с металлическими деталями, как тот же блендер, будет стоить гораздо дороже блендера с быстро стирающимися пластиковыми деталями. И от этой ценовой разницы производитель и играет».

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

«20-30 лет назад пластик так широко не использовался, были совсем другие материалы. Естественно больше использовался металл. То есть вещи эти служат дольше просто потому, что там использовались материалы, которые были известны на то время. И в основном это был металл. А сегодня есть уже более современный пластик, который можно использовать в деталях, в том числе механизмах, но он, к сожалению, не столь долговечен, как металл. А все, что с металлом, уже чрезвычайно дорого, разница даже не в два, а порой в три, четыре или пять раз в цене. Поэтому я не отношусь с доверием к теории, что производитель делает специально, чтобы быстрей ломалось. Нет, он делает вещи разных ценовых категорий: эконом-класс, премиум-класс. От этого и зависит, сколько служат вещи», — заключает Марина Петрухина.

Читайте самое актуальное в разделе «Экономика«

www.pravda.ru

Почему вы не выполнили задание вовремя?: варианты ответов

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

«Задание почти выполнено, остались совсем незначительные детали»

1. Неплохой ответ, потому что дается конкретное объяснение. Хотя, конечно, хороший сотрудник обязан держать начальника в курсе деталей и сообщать заранее, если что-то не удается выполнить вовремя.

2. Хорошее объяснение, которое следовало бы уточнить: сколько именно работы сделано, как сделано, какие детали остались. Необходима конкретика. Заодно следовало бы оговорить причины возникшей ситуации.

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

«Случилось ЧП, и мне пришлось восстанавливать всю информацию»

1. Я не стала бы ставить оценку такому объяснению, потому что данный ответ — просто констатация факта. Если ЧП произошло, сотрудник не виноват. А если работник говорит неправду, это всегда легко проверить.

2. Логичный ответ. Форс-мажор случается со всеми. К тому же, что важно, сотрудник не отказался от работы, а восстановил все данные.

3.Увы, такое случается. Если это единичный случай, то начальнику придется с этим смириться. Если такое происходит часто, руководителю следует уделить внимание повышению надежности IT-систем и научить подчиненных работать, сохраняя резервные копии.

«Я не рассчитал усилий и думал, что справлюсь»

1. Мне как руководителю такой ответ понравился. В данной ситуации мне в первую очередь важно, соответствует ли оправдание действительности. Все мы порой не справляемся с работой вовремя. Главное, чтобы ответ прозвучал честно. Иногда лучше сказать: «Да, я не справился». Не нужно лгать и приводить аргументы, не относящиеся к сути дела.

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

3. Подчиненный демонстрирует понимание важности сроков и качества, но оказался не совсем готов профессионально. Начальнику стоит уделить больше внимания профессиональному развитию сотрудника.

«Я сделал все что смог»

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

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

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

«Никто в отделе не справился бы лучше меня»

1. Кому давали задание: сотруднику персонально или всему отделу? Если это входило в обязанности подразделения, почему руководитель спрашивает ответ только с одного работника? А если задание получил один человек, то почему он ссылается на других? Пока вопросов больше, чем ответов.

2. Подчиненный демонстрирует стремление выполнить задачу на высоком уровне. Если это действительно так, то начальнику следует лучше планировать работу по времени и, возможно, выделять на нее больше времени.

«Вы не дали мне нужных ресурсов»

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

2. Где же раньше был сотрудник? Вы специалист, это ваши обязанности, и вам следует самому формировать план работы. Начальник не должен неотступно ходить за подчиненным и разбираться во всех тонкостях работы специалиста. Взяв задание и не выполнив его, сотрудник подводит не только начальника, но и весь отдел, партнеров, клиентов, а то и компанию.

«Вы дали мне невыполнимое задание»

1. Да, действительно, задания бывают труднодостижимыми, но о том, что задача невыполнима, стоило подумать и сообщить начальнику заранее. Когда сотрудник уже постфактум упрекает руководителя в сложности поставленной задачи, это не аргумент.

2. Безобразный ответ. Во-первых, если задание действительно сложное, зачем вы его взяли? Либо выполняйте задание, либо оговаривайте возможные проблемы заранее. Руководитель задумается: зачем мне работник, который не может справиться с задачей? Сотрудник расписывается в собственной беспомощности.

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

Наталья Чудова
По материалам «Труд»

hr-portal.ru

Почему мы и дальше будем срывать сроки / Habr

    Об очевидных вещах нужно писать снова и снова. Чтобы они не теряли своей очевидности в глазах людей. Чтобы люди, подгоняемые гнетом действительности не могли отринуть очевидное, как малозначимое. Чтобы они не могли придумать хитроумных псевдоаргументов с целью оправдать свое пренебрежительное отношение к очевидным вещам. Очевидные вещи такого не прощают. И планирование проектов тому не исключение.

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

Постановка задачи

    Все в нашей цивилизации делается с какой-то целью, во всяком случае так принято считать, и уж во всяком случае любому, даже самому неразумному проекту, можно, постаравшись приписать какую-то цель. Все так и с программированием. Если вы занимаетесь программированием не только для себя, а также не пребываете в уютной вселенной опенсорса, то наверняка замечали вокруг себя людей, которые всеми правдами и неправдами пытаются получить от вас ответ, когда же наконец вы закончите. Кто-то говорит, что эти люди — заказчики, кто-то — тимлиды, некоторые даже говорят что это проект-менеджер. Говоря же прямо, кто этот человек и когда он задаст свой неудобный вопрос — не знает никто.
    Достоверно известно лишь одно — чем больше раз человек задает этот вопрос, тем большим негодованием преисполнен его голос, и тем большее давление он будет пытаться на вас оказать. Задача, казалось бы ясна, но специфика вопроса не дает на него ответить. Тут причины разнятся — и зависят от опыта отвечающего. Менее опытный склонен считать, что не знает ответа на этот вопрос. Человек же более опытный часто оказывается терзаем подозрениями, что не сможет дать такой ответ, который бы понравился вопрошающему, и поэтому в его душе происходит битва между ангелом искренности и демоном тактичности(впрочем, теологические роли могут различаться в зависимости от ситуации и целей отвечающего).
    Статистика показывает, что какой бы ответ не был дан, он оказывается либо неправильным, либо неприемлемым.

Взгляд со стороны

    Одна из величайших преград во взаимопонимании людей спрашивающих и программистов отвечающих заключается в том, что люди спрашивающие представляют себе написание программного кода как процесс, тождественный производственному процессу чего-то материального. И что бы не говорили менеджеры(в попытках привлечь клиента), пытающиеся правдами и неправдами доказать, что планирование сроков при разработке ПО — дело точное и обычное, различие тут есть, а значит и подход должен быть иной.
    Беда в том, что эта она из тех ситуаций, когда люди предпочтут услышать приятную ложь, нежели неприятную правду. И если вы попробуете совершенно правдиво сказать клиенту, что вы не знаете сколько времени займет проект, и попытаетесь объяснить почему именно установление сроков невозможно, то скорее всего клиент уйдет к вашим конкурентам, назвавшим сроки. Однако и расстраиваться тут не следует — ваши конкуренты тоже не знают сроков.
    В этой ситуации можно понять каждого. Клиенту хочется дать денег и получить результат, ему искренне плевать как вы это сделаете, ему просто нужны гарантии, что вы это сделаете и сделаете к определенному сроку. Вам не хочется врать человеку, что достойно всяческих похвал. Вашим конкурентам просто хочется получить заказ. В итоге проблемы у всех: вы сидите без работы, клиент не получает проект вовремя, конкуренты получают показательный геноцид нервных клеток и уникальную возможность работать гораздо больше при том же самом бюджете.

Два процесса

    В каждом производстве условно есть два этапа: разработка продукции и ее производство. Что такое разработка? Это затраты времени, в которые входит разработка дизайна, подбор сырья, элементной базы, создание производственных линий. Производство — это тот промежуток времени, отводимый на превращение чертежей и сырья в конечный продукт. Да простят меня диванные и дипломированные экономисты.
    Такая упрощенная модель в каком-то роде справедлива и для создания материальных продуктов и для написания программ. В идеальном мире. В реальном мире есть свои особенности. Оглянитесь вокруг — почти все предметы, окружающие вас — это продукт массового производства. Для компьютеров, холодильников, квартир, кошачьих лотков и велосипедов характерно многократное использование результатов этапа разработки. Т.е. по одному чертежу и налаженному тех-процессу выпускается огромное количество изделий, срок выпуска каждого из которых прописан и обоснован на этапе разработки. Вытачивание детали — детерминированный по времени процесс, сборка узла — тоже, и т.д. Суммируя все эти сроки можно получить точный срок выпуска конечного продукта(в рамках погрешностей). Достаточно просто не так ли? Простоты добавляет то, что люди понимают что, они выбирают из имеющихся моделей на рынке, и что если они хотят получить что-то отличное от стандартного изделия, то им необходимо найти специалиста, который мог бы изделие модифицировать или изготовить требуемое с нуля. С соответствующими затратами на проектирование и их работу.
    Культура потребления здесь присутствует, и все люди понимают разницу между массовым товаром и товаром сделанным на заказ. В том числе разницу в сроках поставки того и другого. И вообще, у людей складывается впечатление, что задачи нужно решать имеющимися средствами. И они их так и решают. Идиллия — не иначе.
    В случае программирования все переворачивается с ног на голову. Во-первых, фаза проектирования по сути никогда не заканчивается — как бы близко не был конец проекта, все равно нужно будет искать решения, что есть процесс творческий, а значит детерминизмом по времени тут и не пахнет. Выстроить предельно точную модель даже интернет-магазина и держать ее в голове ни одному человеку не под силу. Приходится постоянно додумывать детали. И никакие спецификации тут не подспорье — они лишь говорят что нужно сделать, но — не как. На вопрос «как» может дать ответ чертеж, но, по иронии, в случае ПО он — и есть готовая программа.
    Во-вторых, необходимость постоянного принятия решений складывается из-за того, что клиент в большинстве случаев подразумевает разработку на заказ, т.е. даже имея готовые модули и наработки не всегда возможно просто взять и собрать их воедино — изменения почти неизбежны. А где есть изменения, почти всегда есть регрессии, что означает опять таки потерю времени.
    В-третьих, обычно программы не могут(на момент января 2013) разрабатываться конвейерным способом — программисты не могут быть так же незаметно заменены, как рабочие на заводе. Нет, правда не могут! В небольшой команде потеря времени от смены или ухода разработчика будет очевидна. В огромной компании, где программистов десятки и сотни, может возникнуть иллюзия того, что сотрудника можно незаметно заменить. Внешне незаметно — можно, но потеря времени неизбежна, поскольку любой новый программист не сможет сразу въехать в процесс разработки и должен будет исследовать уже имеющийся код предшественника, что снова приводит нас к потерям времени. Изменения же в командном составе программистов есть явление закономерное.
    Копирование программы — аналог стадии производства в материальном мире на практике абсолютно не значимо для получения продукта. Все силы уходят в стадию разработки, гораздо более трудоемкую, а главное — плохо предсказуемую.

Спекуляция временем

    Практически все заказчики не хотят работать с не детерминированной моделью поставок, и у них нет понимания того, что программный продукт, который они хотят получить не производится, а придумывается на ходу. А мыслительный процесс нормируется плохо. Но гарантий и определенности хочется все равно. Плохо также то, что большинство заказчиков не могут и не хотят понять этого. И объяснить это тяжело — вы бы сами поверили доводам одного человека о том, что ответа нет, когда рядом стоит еще 10 человек, которые этот ответ готовы дать?
    Спекуляция на угадывании срока уже давно и прочно закрепилась как инструмент конкуренции, а сам срок уже перестал что-то значить. Какой смысл определять то, что в принципе невозможно определить? Какой смысл говорить правду человеку, который ее не хочет слышать? Масла в огонь подливает еще и то, что для некоторых проектов, срок определить все же реально, в результате чего клиент, глядя на то, как ему быстро и четко настроили 1С или сделали промо-сайт, начинает думать, что подобный механизм оценки сроков будет работать и для других проектов…

Триумф пунктуальности

    Дойдя до этого места, определенный круг читателей возможно станет подозревать автора в низкой компетенции, которую он пытается оправдать путем выставления задачи определения сроков проекта в нерешаемом свете. Вовсе нет! Я никоим образом не отрицаю того, что определить срок сдачи проекта возможно. Но давайте будем честны с собой.
    Много ли программирования в создании однотипных сайтов-визиток/интернет-магазинов/андройд-клиентов? В случае отлаженного тех-процесса, где различия между проектами минимальны, сроки будут точны. При этом упускается из внимания то, что вся фаза проектирования уже фактически выполнена. Даже некоторые программисты ведутся на эту ситуацию, оставляя у себя в голове твердую уверенность в том, что во всех программных проектах оценка сроков — вещь реальная.
    Занимает ли ваш проект больше месяца-двух? Обычно на таких сроках ошибка не очень велика, проект небольшой и погрешности при измерениях времени такие же. Однако они есть — если вы закончили проект за полтора месяца вместо месяца или двух, то вы серьезно ошиблись. Ваш прогнозируемый срок не совпал с реальным — а что будет если экстраполировать его на проекты больше длительности?
    Если вы все же считаете, что определение точное сроков возможно, то либо вы гений, либо вам следует в порядке эксперимента сменить предметную область программирования, чтобы проверить, будут ли ваши прогнозы сбываться с той же точностью как и на текущем поле деятельности.

Что делать?

    Если вы хотите, чтобы ваш прогноз был если не точен, то хотя бы не оказался меньше реального срока разработки, то вариантов всего два — излишняя подстраховка и смена условий задачи.
    Первый подход — это классика, когда вы берете время разработки и умножаете его на… то число, которое подскажет ваша интуиция. Нельзя сказать, что этот метод плох, единственное в чем его можно упрекнуть, так это в неоптимальности. Однако в свете того, что величина сроков часто обратно пропорциональна вероятности получения проекта, универсальным этот метод назвать нельзя.
    Когда с увеличением сроков выгадать не удается, следует попробовать изменить условия проекта так, чтобы они были максимально приближены к имеющимся у вас наработкам или готовым решениям. Какую-то долю определенности это внесет. По хорошему этот метод нужно применять для всех проектов, публикуемых на фрилансе не-специалистами. Дабы повысить градус адекватности и сэкономить деньги этих же не-специалистов, а так же нервы специалистов.

habr.com