Comments 49
+1
Лучше подойдет раздел «Я негодую» или «Я пиарюсь».
вот у нас такая точно история. Каждый понедельник после втречи с заказчиком начинается с переделывания всего, что было утверждено им на позапрошлой неделе
Бегите из такой конторы ) Я 2 года потерял на переделки проекта из за того, что манагер, ответственный за общение с заказчиком, был по профессии врач, а строил из себя крутого IT спеца. В итоге крайними оставались кодеры, которые видите ли не предусмотрели того и того.
Дальше будет только хуже.
Дальше будет только хуже.
Валите оттуда побыстрее ) Я уже валю из такой компании.
Вот именно телепатических способностей и не хватает чаще всего, потому что клиент как девушка — говорит одно, а думает совсем о другом, и потом виноват именно ты, потому что не прочитал эти мысли.
А вот то, что команда начинает работать по изменённому ТЗ не должно волновать ни тимлидера, ни рядовых программистов, если они сидят на ЗП.
А вот то, что команда начинает работать по изменённому ТЗ не должно волновать ни тимлидера, ни рядовых программистов, если они сидят на ЗП.
На одном из многочисленных тренингов я услышал гениальнейший подход: спрашвать у заказчика «Зачем вам это надо?» до тех пор (естественно, в интеллигентной форме), пока заказчик сам не поймет, а зачем же ему это надо. Подобная настойчивость не раз и не два раза избавляла меня от различных «брыканий» требований.
Лично я опрашиваю заказчика на предмет требований до тех пор, пока сам не пойму бизнес-процесс и возможные его косяки. Помогает, я гарантирую это.
Лично я опрашиваю заказчика на предмет требований до тех пор, пока сам не пойму бизнес-процесс и возможные его косяки. Помогает, я гарантирую это.
Именно так и должно быть. Если вы работаете с «нецивилизованными» заказчиками, и хотите чтобы они остались довольны и не плевались потом. Нужно все делать за них.
А как вы формулируете этот вопрос, чтобы заказчик, с одной стороны, не решил что с ним не хотят сотрудничать, а с другой — чтобы он не понял чтобы ему не показалось, что его держат за идиота?
Формулирую всегда по-разному, но обычно:
1) общение происходит очно и только очно;
2) показываю заинтересованность в процессе, в его особенностях. Я не гений и не могу знать всех процессов, а также бывают случаи, когда в нем (процессе) есть некоторое ноу-хау или полезный приемчик.
3) использую рисунки, эскизы прямо «на салфетках». Когда кусок логики перед глазами, он и воспринимается по-другому, нежели «на слух».
Главное: не задавать вопросы «на отъебись».
1) общение происходит очно и только очно;
2) показываю заинтересованность в процессе, в его особенностях. Я не гений и не могу знать всех процессов, а также бывают случаи, когда в нем (процессе) есть некоторое ноу-хау или полезный приемчик.
3) использую рисунки, эскизы прямо «на салфетках». Когда кусок логики перед глазами, он и воспринимается по-другому, нежели «на слух».
Главное: не задавать вопросы «на отъебись».
Я вас расстрою, но программисты как ни странно очень сильно не любят переделывать одно и тоже по три сотни раз. Как правило люди готовы даже работать за меньшие деньги, но что бы было интересно. И это правильно.
И заставляя программистов переделывать одно и тоже вы можете спровоцировать текучку кадров, что для компании не выгодно из-за расходов по введению в дело новых сотрудников.
И заставляя программистов переделывать одно и тоже вы можете спровоцировать текучку кадров, что для компании не выгодно из-за расходов по введению в дело новых сотрудников.
У нас похожая история)
мне кажется любой договор должен учитывать изменения тз в разумной степени в процессе разработки чего либо, степень разумности как раз IT-лидер и должен установить, тем самым избавив себя от лишних трудностей, ну и конечно же изменения тз в процессе должны давать какую то прибавку к бюджету.
Но что именно вкладывают в понятие IT-лидера компании и почему их поиски не приносят желаемых результатов?
Ответа на вопрос, поставленный в начале топика, я так и не увидил. Вообще, тема довольно заезженная, но интересная, если суметь разобраться и «разжевать» другим.
У профессионального IT-лидера регулярные изменения ТЗ учитываются по формуле «Любой каприз за Ваши деньги».
P.S. Не могу назвать профессионалом того, кто берется за сложный проект с ограничением сроков и бюджета.
«Время, качество цена. Выбирай любые два» — это закон.
P.S. Не могу назвать профессионалом того, кто берется за сложный проект с ограничением сроков и бюджета.
«Время, качество цена. Выбирай любые два» — это закон.
«Время, качество цена.»
Три хочет заказчик.
Два — оптимист менеджер.
Один — реалист программист.
Три хочет заказчик.
Два — оптимист менеджер.
Один — реалист программист.
Поймал себя на попытке два раза поставить вашему комментарию "+".
Ещё добавлю, что очень часто заказчик принимает решения об изменении требования после рассмотрения готовой части системы. И это нормально (если речь идёт о небольших, не больше 3-4 тысяч часов проектах, для больших разговор, обычно, несколько иной).
Я очень даже понимаю заказчиков, которые, увидев в живую то, что они описали в ТЗ, осознавали, что всё совершенно не так, как им хочется, и кардинально меняли большое количество функционала.
Тут важно, чтобы лидер (кстати, так и не понял, чем он в данной формулировке отличается от руководителя проектов) чётко объяснил заказчику, что возможно сделать быстро, а что займёт дополнительное время и, конечно, повлечёт дополнительные расходы со стороны заказчика. Дальше всё зависит от дипломатических способностей лидера и адекватности клиента.
Кстати, второй стороной этой медали является умение лидера успокоить команду, которая, обычно, бунтует против изменений.
Ещё добавлю, что очень часто заказчик принимает решения об изменении требования после рассмотрения готовой части системы. И это нормально (если речь идёт о небольших, не больше 3-4 тысяч часов проектах, для больших разговор, обычно, несколько иной).
Я очень даже понимаю заказчиков, которые, увидев в живую то, что они описали в ТЗ, осознавали, что всё совершенно не так, как им хочется, и кардинально меняли большое количество функционала.
Тут важно, чтобы лидер (кстати, так и не понял, чем он в данной формулировке отличается от руководителя проектов) чётко объяснил заказчику, что возможно сделать быстро, а что займёт дополнительное время и, конечно, повлечёт дополнительные расходы со стороны заказчика. Дальше всё зависит от дипломатических способностей лидера и адекватности клиента.
Кстати, второй стороной этой медали является умение лидера успокоить команду, которая, обычно, бунтует против изменений.
UFO just landed and posted this here
Я выражался образно. Просто обычно происходит отторжение (иногда — неявное), люди теряют активность, производительность и постоянно задают себе вопрос: «зачем я это делаю, если всё равно переписывать придётся».
Результат — команда расходится, на местных форумах и в кулуарах быстро идут слухи от обиженных, что компания Х — осиное гнездо, а конкретно ПМ — редкая сволочь :)
Неважно, насколько это правда. Важна, что после этого нанимать новых людей станет сложнее. Факт.
Неважно, насколько это правда. Важна, что после этого нанимать новых людей станет сложнее. Факт.
У нас это называется просто бизнес-аналитик, что, по-моему, вполне логично. Надо проанализировать бизнес заказчика, понять, что ему надо и предложить ТЗ.
Еще раз убеждаюсь как мне повезло — к мнению прислушиваются — даже кое-что реализуют.
В итоге — и почти полная свобода в реализации — и сроки за мной, и самому интересно. Главное — сделать каркас — с учетом всевозможных переделок-перекрасок стен\обоев.
А дальше — сегодня так — а завтра в зеленый цвет — да пожалуйста — еще неделю к сроку и % к оплате.
В итоге — и почти полная свобода в реализации — и сроки за мной, и самому интересно. Главное — сделать каркас — с учетом всевозможных переделок-перекрасок стен\обоев.
А дальше — сегодня так — а завтра в зеленый цвет — да пожалуйста — еще неделю к сроку и % к оплате.
Налицо две проблемы:
— не выстроены отношения с заказчиком;
— отсутствует управление требованиями.
Аналитик вам нужен, как здесь уже отметили. Нужно стать на сторону заказчика, понять что и зачем ему нужно, и что может потребоваться в перспективе.
— не выстроены отношения с заказчиком;
— отсутствует управление требованиями.
Аналитик вам нужен, как здесь уже отметили. Нужно стать на сторону заказчика, понять что и зачем ему нужно, и что может потребоваться в перспективе.
Поддерживаю комментатора: проблема управления требованиями налицо. Абсолютно во всех проектах, на которых я работал как бизнес/системный аналитик требования рано или поздно уходили «кто в лес, кто по дрова».
Тем не менее, разброд и шатание будут всегда, надо просто стараться их минимизировать (Коуз: «Устранить ущерб невозможно»).
Тем не менее, разброд и шатание будут всегда, надо просто стараться их минимизировать (Коуз: «Устранить ущерб невозможно»).
IT-лидер, он как и везде. Лидер это тот, кто умеет зажечь команду, довести начатое до конца, четко видит цели и средства их достижения. Обладает мощной харизмой и чутьем. А то, о чем статья — это не о лидере, а действительно о каком-то аналитике.
> Ведь он может сам организовать свой бизнес.
Это очень сильное преувеличение, для организации бизнеса — особенно в России — требуется целый ряд других психологических качеств.
Кроме того, далеко не каждый, кто может организовать свой бизнес, хочет организовать свой бизнес.
Это очень сильное преувеличение, для организации бизнеса — особенно в России — требуется целый ряд других психологических качеств.
Кроме того, далеко не каждый, кто может организовать свой бизнес, хочет организовать свой бизнес.
Дело в том, что зачастую у заказчика нет умения сформулировать задачу. Чтобы сформулировать задачу нужен технический специалист, желательно с программистским прошлым, который и должен работать с таким заказчиком. Мне кажется, что требовать грамотное ТЗ у заказчика, зачастую далёкого от IT, часто безбожно.
Да у них даже желания формулировать зачастую нет. «Хочу сайт» и всё. Некоторые: «хочу сайт как вот этот и чтоб было еще это и то».
Зачастую от заказчика и не требуют указания технических подробностей. Проблема в том, что заказчик действительно не всегда знает, а зачем ему это нужно и что он хочет конкретно ( как об этом писалось выше). Если он сформулировал зачем и что, даже пусть своим языком, то это уже хорошо. То есть сначала собираются просто требования, бриф, а уже на основе этого составляется ТЗ, в составлении ТЗ заказчик может вообще не принимать участия.
И еще один момент, хорошо если заказчик описывает задачу в меру своей компетенции, а не лезет в ту область где он ничего не понимает ( где он не специалист), например архитектура приложения и дизайн.
И еще один момент, хорошо если заказчик описывает задачу в меру своей компетенции, а не лезет в ту область где он ничего не понимает ( где он не специалист), например архитектура приложения и дизайн.
У нас на «ИТ-лидера» привыкли всех собак вешать, по дели у без дела, то есть: ты руководитель, тебе и за все отвечать, но понятие «все» настолько расплывчато… соответственно и спроси идет даже за вещи, не относящиеся к непосредственной деятельности. Поэтому многие Итшники предпочитают быть рядовыми «строителями», то есть:
1) поставили задачу
2) выполнил
3) отчитался
4) ушел домой со спокойной совестью
1) поставили задачу
2) выполнил
3) отчитался
4) ушел домой со спокойной совестью
Все правильно написано!
>Ответ смотрите сегодня вечером на канале ТНТ!
Хоть бы время уточнили или название передачи. У всех вечера разные могут быть (часовые пояса не забываем)
Хоть бы время уточнили или название передачи. У всех вечера разные могут быть (часовые пояса не забываем)
Все верно, но как-то не о чем… Я бы перенес в блог «Мысли вслух», но такого, кажется, нет.
Может быть дело в том, что в вашем примере не IT лидер, а раб-погонщик других рабов? :]
а как же user stories? полезный подход, и не только к клиентам. и клиенты любят такой «ролевой» подход (мои, не знаю за других). тут и «зачем вам это надо?», и «как это должно выглядеть?», и т.д. и т.п.
UFO just landed and posted this here
«Таким образом, на современном рынке IT, больше всего затребован прораб-телепат с навыками пророковедения, способный прочитать мысли заказчика на расстоянии и предвидеть возможные изменения, чтоб изначально подойти к проекту таким образом, чтоб он был завершен в срок и удовлетворил заказчика.» — в точку!
В любом случае надо общаться с заказчиком, независимо от того работает ли «it-лидер» на зарплате или на проценте. Может дело в том — напрямую с ним общаться или через посредников?
>прораб-телепат с навыками пророковедения
надо открывать в универах новый предмет открывать!
надо открывать в универах новый предмет открывать!
Sign up to leave a comment.
Кто же он такой, отечественный IT-лидер?