Comments 23
Дмитрий, отличная статья и хорошие выводы!
Я, как руководитель веб-студии, тоже давно смотрю на Agile и даже ходил вместе с разработчиками на тренинги, но, судя по всему, максимум, что мы можем делать — это разбивать проект на небольшие этапы, каждый из которых можно сравнительно быстро сделать.
Увы, все проблемы, которые вы описали, актуальны и очень интересно узнать, как их решают в других веб-студиях.
Я, как руководитель веб-студии, тоже давно смотрю на Agile и даже ходил вместе с разработчиками на тренинги, но, судя по всему, максимум, что мы можем делать — это разбивать проект на небольшие этапы, каждый из которых можно сравнительно быстро сделать.
Увы, все проблемы, которые вы описали, актуальны и очень интересно узнать, как их решают в других веб-студиях.
На Сайте-2011 про Agile рассказывал Владимир Завертайлов из Сибирикса; как я понял, у них есть такой опыт. Но спросить не успел.
Роман!
Мы с заказчиками (максимально адекватными) поступаем обычно так — вначале делаем базовый проект, который уже можно пускать в интернет, а дальнейшее его развитие (добавление и расширение функционала) делаем уже по Agile.
Чаще всего так выходит проще, и в результате первой итерации клиент уже имеет готовый продукт, который уже может решать его задачи.
А убедить работать так на начальном этапе — очень и очень сложно.
Мы с заказчиками (максимально адекватными) поступаем обычно так — вначале делаем базовый проект, который уже можно пускать в интернет, а дальнейшее его развитие (добавление и расширение функционала) делаем уже по Agile.
Чаще всего так выходит проще, и в результате первой итерации клиент уже имеет готовый продукт, который уже может решать его задачи.
А убедить работать так на начальном этапе — очень и очень сложно.
Пока а России главный фактор выбора — стоимость проекта, о такой модели можно пока только мечтать.
Дмитрий, спасибо, замечательная статья. Пробуем применять Agile на старых клиентах, с кем сложились доверительные отношения. Пока не все получается, но из всех существующих моделей работы с заказчиком и для нашего внутреннего планирования agile видится как самый правильный вариант.
Подписываюсь под каждым ваши словом)
Подписываюсь под каждым ваши словом)
Если есть взаимное доверие, то ситуации:
— Вы издеваетесь? Там 100 страниц вашим птичьим языком, я его не осилил, понадеялся на ваш профессионализм.
— Окей, переделаем, платите деньги.
— Вот еще, я столько денег заплатил, переделывайте бесплатно.
— Не будем.
— А мы не заплатим, пока не переделаете.
возникнуть не должно.
— Вы издеваетесь? Там 100 страниц вашим птичьим языком, я его не осилил, понадеялся на ваш профессионализм.
— Окей, переделаем, платите деньги.
— Вот еще, я столько денег заплатил, переделывайте бесплатно.
— Не будем.
— А мы не заплатим, пока не переделаете.
возникнуть не должно.
Не соглашусь. Чем больше заказчик доверяет разработчику, тем меньше у него мотивации вчитываться в договор.
Вы точно 10 лет общались с заказчиками?
Нет ничего хуже ситуации, когда заказчик, питая к вам полное доверие, наконец находит время прочесть контракт и, о май год, они меня хотели поиметь! Мало того, что написано непонятно, так они еще и меня крабом поставить хотят своими условиями (которые на самом деле вполне разумные при разъяснении)!
И где доверие?
Ведь неясности проще разъяснять человеку в нейтральном состоянии, нежели в мыслях «они меня хотят поиметь».
Нет ничего хуже ситуации, когда заказчик, питая к вам полное доверие, наконец находит время прочесть контракт и, о май год, они меня хотели поиметь! Мало того, что написано непонятно, так они еще и меня крабом поставить хотят своими условиями (которые на самом деле вполне разумные при разъяснении)!
И где доверие?
Ведь неясности проще разъяснять человеку в нейтральном состоянии, нежели в мыслях «они меня хотят поиметь».
Вообще кошмарная фраза.
Заказчик должен четко понимать все детали контракта. Чем раньше, тем лучше — на берегу.
Обскурити — это плохо и отвратительно. Выяснять что-то в процессе, когда уже есть негативный опыт (а он почти всегда есть) — непрофессионально.
Заказчик должен четко понимать все детали контракта. Чем раньше, тем лучше — на берегу.
Обскурити — это плохо и отвратительно. Выяснять что-то в процессе, когда уже есть негативный опыт (а он почти всегда есть) — непрофессионально.
Должен — не значит, что будет. В теории все замечательно, есть результат, договору соответствует — деньги на бочку. А на практике это часто конфликтная ситуация, которая решается ДАЛЕКО не всегда за счет заказчика. С этим приходится считаться. Это не только мой опыт.
При конфликте (а это постоянно бывает) должен быть организован нормальный процесс поиска решения проблемы — это совершенно нормально, не надо сразу нестись в суд.
Заказчики всякие бывают, но договориться можно с большим количеством.
Но бывает всякое, и именно для этого «вы можете обманывать заказчика, приписывая лишние часы. „
На самом деле у вас, извините, совершенно неправильный подход к бюджетированию и выставлению цены. У меня опыт поменее, с 2003 года, но рассуждать могу разумно.
Попробуйте ради интереса узнать, как выставляется цена у грандов — Датаарта или Дигитал Дизайна. Даже если брать “чистый» ИТ проект, без шелухи в виде продажников, менеджеров и прочего, то цена часа программера в бюджете умножается на 5-10. И это вполне справедливые риски — разработчики болеют и косячат, их замена стоит денег, они ходят в отпуск, сидят в помещении, пользуют компьютеры и так далее. Вообще, расчет ROI для софтверной компании — увлекательное занятие, сразу многие моменты становятся понятными.
Клиент потому и готов платить такие деньги, только бы не слышать — «Вася заболел, извините, проект встал.» Клиенту нужен результат, который стоит денег.
И часы не «приписываются», идет нормальный расчет бюджета, который можно (и иногда нужно!) показывать клиенту.
Заказчики всякие бывают, но договориться можно с большим количеством.
Но бывает всякое, и именно для этого «вы можете обманывать заказчика, приписывая лишние часы. „
На самом деле у вас, извините, совершенно неправильный подход к бюджетированию и выставлению цены. У меня опыт поменее, с 2003 года, но рассуждать могу разумно.
Попробуйте ради интереса узнать, как выставляется цена у грандов — Датаарта или Дигитал Дизайна. Даже если брать “чистый» ИТ проект, без шелухи в виде продажников, менеджеров и прочего, то цена часа программера в бюджете умножается на 5-10. И это вполне справедливые риски — разработчики болеют и косячат, их замена стоит денег, они ходят в отпуск, сидят в помещении, пользуют компьютеры и так далее. Вообще, расчет ROI для софтверной компании — увлекательное занятие, сразу многие моменты становятся понятными.
Клиент потому и готов платить такие деньги, только бы не слышать — «Вася заболел, извините, проект встал.» Клиенту нужен результат, который стоит денег.
И часы не «приписываются», идет нормальный расчет бюджета, который можно (и иногда нужно!) показывать клиенту.
Я знаю, как происходит ценообразование в крупных компаниях. Но во-первых, я пишу не для них, они и без меня разберутся :) Во-вторых, менеджеров вы зря к «шелухе» отнесли, их доля в смете бывает вполне значимой.
Упрек в неправильном подходе к бюджетированию не понят, я про это вообще не писал. Как рассчитывается человеко-час разработчика и вообще ценообразование — тема вообще отдельная.
Ну и наконец я потерял нить — о чем мы спорим- то? :) Что должен быть организован процесс — понятно, что лучше обойтись без него — тоже.
Упрек в неправильном подходе к бюджетированию не понят, я про это вообще не писал. Как рассчитывается человеко-час разработчика и вообще ценообразование — тема вообще отдельная.
Ну и наконец я потерял нить — о чем мы спорим- то? :) Что должен быть организован процесс — понятно, что лучше обойтись без него — тоже.
Если есть хороший договор, то этой ситуации тоже не возникнет. Не хочешь платить деньги? В суд.
Часто встречал прямо магическую веру в хороший договор.
По моему опыту написания технических заданий и составления договоров, к сожалению, вы не убережете себя от всех нюансов. Фактически, есть несколько вариантов. Например, вариант, когда все неописанное в договоре трактуется в пользу исполнителя. В этом случает вы формально правы, но если вы разработали плохо или не то — то вы потеряли заказчика.
Бизнес веб-студии — это услуги, и сарафанное радио играет очень большую роль в рекомендациях клиентов.
Другой вариант — когда вы в договоре прописываете каждую мелочь. Но в этом случае затраты на документооборот очень сильно возрастают.
Возможно, это оправданно для очень дорогих проектов. Но для небольших — вряд ли.
По моему опыту написания технических заданий и составления договоров, к сожалению, вы не убережете себя от всех нюансов. Фактически, есть несколько вариантов. Например, вариант, когда все неописанное в договоре трактуется в пользу исполнителя. В этом случает вы формально правы, но если вы разработали плохо или не то — то вы потеряли заказчика.
Бизнес веб-студии — это услуги, и сарафанное радио играет очень большую роль в рекомендациях клиентов.
Другой вариант — когда вы в договоре прописываете каждую мелочь. Но в этом случае затраты на документооборот очень сильно возрастают.
Возможно, это оправданно для очень дорогих проектов. Но для небольших — вряд ли.
По практике знакомых, суды чаще всего встают на сторону заказчиков. К тому же, веб-разработка штука специфическая, попробуй докажи судье, что функционал выполнен в соответствии — если клиенту не нравится.
Шикарная статья.
Надо будет попробовать попредлагать заказчикам поработать по такой схеме, а то нынче часто бывает, что заказчик оплату производит по каскадной схеме, а работу требует по Agile, постоянно и по первому чиху )
Надо будет попробовать попредлагать заказчикам поработать по такой схеме, а то нынче часто бывает, что заказчик оплату производит по каскадной схеме, а работу требует по Agile, постоянно и по первому чиху )
Расскажите, пожалуйста, о результатах, если будут. Тоже по факту так и получается.
Обязательно. На самом деле статья очень полезная, надо только понять как организовать так, чтобы это работало и попробовать воплощать это на практике. Тем более, что опять же на практике по сути к этому и приходишь. Самое сложно, это донести заказчику, почему он должен принимать работу и платить по такой схеме.
К сожалению большинство заказчиков очень далеки от всех новшеств в разработке. Для некоторых вообще дико звучит, как это делать без плана и не знать, когда закончишь. Требования договора и формального срока сдачи приемки проекта всегда будут сводить на нет все попытки делать по agile. Agile подход пытался применять еще 3 года назад, однако если разработчик готов применять данную модель, то заказчик очень и очень редко. Так что работать надо с заказчиком, если он к этому готов конечно, вести образовательную работу и разъяснительную, если он ваш постоянный клиент конечно.
Sign up to leave a comment.
Agile в заказной веб-разработке