О том, как надо и как не надо вести ИТ проекты.
О том, как надо и как не надо вести ИТ проекты
Я – ИТ-шник.
Я – ИТ-шник по роду занятий, по призванию, по интересам и, частично, по хобби.
И я этим ИТ-шным делом занимаюсь очень давно.
Уже и не помню, с какого года, но это и не важно.
Важно, что я этим начал заниматься еще в эпоху EC ЭВМ, и продолжил от момента появления IBM совместимых компьютеров по сю пору.
Я сам когда-то писал программы, потом - собирал группы по написанию и внедрению программ.
Я всегда этим занимался, и выполнил, наверное, уже тысячи всяких проектов.
Большую часть из которых успешно сдал для пользы Заказчика и своей:)
И за это время, конечно, у меня накопилось свое понимание правильных методов выполнения проектов. У кого-то тоже, наверняка, накопилось свое понимание, которое вполне может быть другим.
Но известно, что главная истина состоит в том, что «Всяко бывает».
Особенно в ИТ.
Долгий опыт учит, что бывает по-всякому.
Бывают успешные и не успешные проекты.
Бывает, что применяют хорошие методы, и они дают успех проекту.
А бывает, что и не дают.
Бывает, что применяют плохие методы, но проект все-таки успешно выполняется.
А бывает, что и нет.
Китайцы говорят «На вершину горы ведет тысяча дорог». То есть успешный проект можно выполнить разными способами.
Но все равно, есть некоторая общая мудрость. Эту мудрость надо знать.
И мне казалось, что все ее знают.
Но оказывается, что правильные вещи нужно регулярно повторять. Не все их знают и, что совсем удивительно, не все их хотят знать.
Вот, например, в автомобилях.
Есть одна общая истина.
Есть только один способ успеть вовремя куда-то приехать.
Этот способ – «Раньше выехать».
Можно много говорить о методах, стилях вождения, об экстремальном вождении и методах удержаться в повороте на высокой скорости.
Но все это – фигня, по сравнению с универсальным и действенным способом «Раньше выехать».
И вот точно такой же способ есть при сдаче ИТ проектов Заказчику.
Вот главный секрет успешной сдачи вовремя:
Чтобы успешно и в срок сдать проект Заказчику нужно его сдавать несколько раз и заранее!
Это означает, что нужно как можно раньше собрать полный проект.
И как можно раньше проект начать сдавать Заказчику.
Следствие :
– если вы проект сдаете Заказчику первый раз в день окончания сроков, то сдать проект практически невозможно. Или это очень маленький проект, или речь идет о чем-то готовом и очень простом.
Как вы собираетесь идти к Заказчику и говорить с ним, если вы приходите к нему в день окончания сроков впервые?
Здесь возможны два варианта:
1. Вы лучше всех знаете, как надо делать проекты и лучше всех знаете, что нужно Заказчику и какие у него задачи. И лучше всех знаете, как надо делать именно это проект и как его сдавать.
2. Или вы не лучше Заказчика знаете его потребности. Но тогда почему вы слушаете Заказчика только в последний день?
Всё просто. Сдать заказ можно успешно и вовремя только в том случае, если вы заранее приходите к Заказчику с проектом и начинаете сдавать.
Когда вы первый раз показываете проект – Заказчик всегда недоволен.
Хотя бы потому, что он многое представлял себе иначе. Даже если у вас есть подробное ТЗ.
Во многих случаях Заказчик и не читал детально ТЗ.
А вот когда вы сделаете первый показ, когда Заказчик выпустит весь свой пар и все свое негодование, тогда можно написать список доработок.
Потом этот список доработок нужно сделать.
Тем временем Заказчик привыкнет к проекту, будет уже не просто кричать, что «все плохо», а будет уже работать по списку доработок.
И методом многократного подхода можно надежно и во-время сдать проект.
Все просто. Очень надеюсь, что все ИТ-шники это знают.
Но я тут недавно подключил к работе дополнительную группу программистов.
И вот девушка менеджер этой группы меня потрясла.
Во-первых, она хотела предоплату за разработку сайта.
Я в своей долгой и бурной жизни не сталкивался с требованием полной предоплаты за разработку сайта.
Чаще всего применяют классическую схему – аванс, потом выполнение работ, после подписания актов, окончательная оплата.
Но в ИТ «Всяко бывает». Я тут недавно встречался с директором одной ИТ-фирмы. Спросил их директора, работают ли они по предоплате за разработку. Он задумался, но не смог вспомнить, чтобы где-то в разработке была 100% предоплата.
Второе, чем меня потрясла эта ИТ-менеджер. Она считала, что можно проект сдать в оговоренный срок, ни разу не показав заранее полной сборки этого проекта. То есть она показывала разные куски и предлагала их проверять.
А мои слова, что когда мы увидим полную сборку, то ничего не будет работать, она полностью отвергала.
Излишне говорить, что так все и получилось. Когда они сделали в последний момент полную сборку, то ее было невозможно смотреть из-за ошибок и глюков.
Я попросил просто убрать эту девушку из этого проекта. Попросил дополнительное время на проект.
И все пошло по классической схеме.
Все пошло хорошо.
Кстати, так как девушка менеджер, которая здесь упоминалась, совершенно ничего не хотела и не умела слушать, то, отчасти это и вдохновило этот пост о Великой силе ЖЖ http://pvn123.livejournal.com/233907.html :)
Если вы хотите что-то сказать, но вас не слушают – скажите это в ЖЖ.
Кроме того, в ЖЖ гораздо больше аудитория:)
Я – ИТ-шник.
Я – ИТ-шник по роду занятий, по призванию, по интересам и, частично, по хобби.
И я этим ИТ-шным делом занимаюсь очень давно.
Уже и не помню, с какого года, но это и не важно.
Важно, что я этим начал заниматься еще в эпоху EC ЭВМ, и продолжил от момента появления IBM совместимых компьютеров по сю пору.
Я сам когда-то писал программы, потом - собирал группы по написанию и внедрению программ.
Я всегда этим занимался, и выполнил, наверное, уже тысячи всяких проектов.
Большую часть из которых успешно сдал для пользы Заказчика и своей:)
И за это время, конечно, у меня накопилось свое понимание правильных методов выполнения проектов. У кого-то тоже, наверняка, накопилось свое понимание, которое вполне может быть другим.
Но известно, что главная истина состоит в том, что «Всяко бывает».
Особенно в ИТ.
Долгий опыт учит, что бывает по-всякому.
Бывают успешные и не успешные проекты.
Бывает, что применяют хорошие методы, и они дают успех проекту.
А бывает, что и не дают.
Бывает, что применяют плохие методы, но проект все-таки успешно выполняется.
А бывает, что и нет.
Китайцы говорят «На вершину горы ведет тысяча дорог». То есть успешный проект можно выполнить разными способами.
Но все равно, есть некоторая общая мудрость. Эту мудрость надо знать.
И мне казалось, что все ее знают.
Но оказывается, что правильные вещи нужно регулярно повторять. Не все их знают и, что совсем удивительно, не все их хотят знать.
Вот, например, в автомобилях.
Есть одна общая истина.
Есть только один способ успеть вовремя куда-то приехать.
Этот способ – «Раньше выехать».
Можно много говорить о методах, стилях вождения, об экстремальном вождении и методах удержаться в повороте на высокой скорости.
Но все это – фигня, по сравнению с универсальным и действенным способом «Раньше выехать».
И вот точно такой же способ есть при сдаче ИТ проектов Заказчику.
Вот главный секрет успешной сдачи вовремя:
Чтобы успешно и в срок сдать проект Заказчику нужно его сдавать несколько раз и заранее!
Это означает, что нужно как можно раньше собрать полный проект.
И как можно раньше проект начать сдавать Заказчику.
Следствие :
– если вы проект сдаете Заказчику первый раз в день окончания сроков, то сдать проект практически невозможно. Или это очень маленький проект, или речь идет о чем-то готовом и очень простом.
Как вы собираетесь идти к Заказчику и говорить с ним, если вы приходите к нему в день окончания сроков впервые?
Здесь возможны два варианта:
1. Вы лучше всех знаете, как надо делать проекты и лучше всех знаете, что нужно Заказчику и какие у него задачи. И лучше всех знаете, как надо делать именно это проект и как его сдавать.
2. Или вы не лучше Заказчика знаете его потребности. Но тогда почему вы слушаете Заказчика только в последний день?
Всё просто. Сдать заказ можно успешно и вовремя только в том случае, если вы заранее приходите к Заказчику с проектом и начинаете сдавать.
Когда вы первый раз показываете проект – Заказчик всегда недоволен.
Хотя бы потому, что он многое представлял себе иначе. Даже если у вас есть подробное ТЗ.
Во многих случаях Заказчик и не читал детально ТЗ.
А вот когда вы сделаете первый показ, когда Заказчик выпустит весь свой пар и все свое негодование, тогда можно написать список доработок.
Потом этот список доработок нужно сделать.
Тем временем Заказчик привыкнет к проекту, будет уже не просто кричать, что «все плохо», а будет уже работать по списку доработок.
И методом многократного подхода можно надежно и во-время сдать проект.
Все просто. Очень надеюсь, что все ИТ-шники это знают.
Но я тут недавно подключил к работе дополнительную группу программистов.
И вот девушка менеджер этой группы меня потрясла.
Во-первых, она хотела предоплату за разработку сайта.
Я в своей долгой и бурной жизни не сталкивался с требованием полной предоплаты за разработку сайта.
Чаще всего применяют классическую схему – аванс, потом выполнение работ, после подписания актов, окончательная оплата.
Но в ИТ «Всяко бывает». Я тут недавно встречался с директором одной ИТ-фирмы. Спросил их директора, работают ли они по предоплате за разработку. Он задумался, но не смог вспомнить, чтобы где-то в разработке была 100% предоплата.
Второе, чем меня потрясла эта ИТ-менеджер. Она считала, что можно проект сдать в оговоренный срок, ни разу не показав заранее полной сборки этого проекта. То есть она показывала разные куски и предлагала их проверять.
А мои слова, что когда мы увидим полную сборку, то ничего не будет работать, она полностью отвергала.
Излишне говорить, что так все и получилось. Когда они сделали в последний момент полную сборку, то ее было невозможно смотреть из-за ошибок и глюков.
Я попросил просто убрать эту девушку из этого проекта. Попросил дополнительное время на проект.
И все пошло по классической схеме.
Все пошло хорошо.
Кстати, так как девушка менеджер, которая здесь упоминалась, совершенно ничего не хотела и не умела слушать, то, отчасти это и вдохновило этот пост о Великой силе ЖЖ http://pvn123.livejournal.com/233907.html :)
Если вы хотите что-то сказать, но вас не слушают – скажите это в ЖЖ.
Кроме того, в ЖЖ гораздо больше аудитория:)