Как стать автором
Обновить

Комментарии 49

Лучше подойдет раздел «Я негодую» или «Я пиарюсь».
Ну почему, очень даже правильная статья. В принципе, с автором я согласен…
Как бы я ничего против статьи не имею. Автор вполне резонно констатирует общие для всех проблемы, но тут лишь констатация. Понимаю, что у него (и не только у него) наболело. А где, собственно, советы и рекомендации?
вот у нас такая точно история. Каждый понедельник после втречи с заказчиком начинается с переделывания всего, что было утверждено им на позапрошлой неделе
Бегите из такой конторы ) Я 2 года потерял на переделки проекта из за того, что манагер, ответственный за общение с заказчиком, был по профессии врач, а строил из себя крутого IT спеца. В итоге крайними оставались кодеры, которые видите ли не предусмотрели того и того.
Дальше будет только хуже.
Валите оттуда побыстрее ) Я уже валю из такой компании.
Вот именно телепатических способностей и не хватает чаще всего, потому что клиент как девушка — говорит одно, а думает совсем о другом, и потом виноват именно ты, потому что не прочитал эти мысли.
А вот то, что команда начинает работать по изменённому ТЗ не должно волновать ни тимлидера, ни рядовых программистов, если они сидят на ЗП.
На одном из многочисленных тренингов я услышал гениальнейший подход: спрашвать у заказчика «Зачем вам это надо?» до тех пор (естественно, в интеллигентной форме), пока заказчик сам не поймет, а зачем же ему это надо. Подобная настойчивость не раз и не два раза избавляла меня от различных «брыканий» требований.
Лично я опрашиваю заказчика на предмет требований до тех пор, пока сам не пойму бизнес-процесс и возможные его косяки. Помогает, я гарантирую это.
Именно так и должно быть. Если вы работаете с «нецивилизованными» заказчиками, и хотите чтобы они остались довольны и не плевались потом. Нужно все делать за них.
А как вы формулируете этот вопрос, чтобы заказчик, с одной стороны, не решил что с ним не хотят сотрудничать, а с другой — чтобы он не понял чтобы ему не показалось, что его держат за идиота?
Формулирую всегда по-разному, но обычно:
1) общение происходит очно и только очно;
2) показываю заинтересованность в процессе, в его особенностях. Я не гений и не могу знать всех процессов, а также бывают случаи, когда в нем (процессе) есть некоторое ноу-хау или полезный приемчик.
3) использую рисунки, эскизы прямо «на салфетках». Когда кусок логики перед глазами, он и воспринимается по-другому, нежели «на слух».

Главное: не задавать вопросы «на отъебись».
Я вас расстрою, но программисты как ни странно очень сильно не любят переделывать одно и тоже по три сотни раз. Как правило люди готовы даже работать за меньшие деньги, но что бы было интересно. И это правильно.

И заставляя программистов переделывать одно и тоже вы можете спровоцировать текучку кадров, что для компании не выгодно из-за расходов по введению в дело новых сотрудников.
У нас похожая история)
мне кажется любой договор должен учитывать изменения тз в разумной степени в процессе разработки чего либо, степень разумности как раз IT-лидер и должен установить, тем самым избавив себя от лишних трудностей, ну и конечно же изменения тз в процессе должны давать какую то прибавку к бюджету.
Или, хотя бы, при постоянной ЗП давать прибавку ко времени.
что, собственно, одно и то же
В результате по деньгам может и да, но по времени во втором случае получается больше. У нас же любят поменять задание в корне и требовать выполнения в те же сроки…
Но что именно вкладывают в понятие IT-лидера компании и почему их поиски не приносят желаемых результатов?


Ответа на вопрос, поставленный в начале топика, я так и не увидил. Вообще, тема довольно заезженная, но интересная, если суметь разобраться и «разжевать» другим.
Потому что на словах они хотят архитекторов, а на деле требуют прорабов.
Они требуют чтобы человек умел решать поставленные перед ним задачи.
Тогда не нужно требовать у прораба диплома архитектора
У профессионального IT-лидера регулярные изменения ТЗ учитываются по формуле «Любой каприз за Ваши деньги».

P.S. Не могу назвать профессионалом того, кто берется за сложный проект с ограничением сроков и бюджета.
«Время, качество цена. Выбирай любые два» — это закон.
«Время, качество цена.»
Три хочет заказчик.
Два — оптимист менеджер.
Один — реалист программист.
Поймал себя на попытке два раза поставить вашему комментарию "+".

Ещё добавлю, что очень часто заказчик принимает решения об изменении требования после рассмотрения готовой части системы. И это нормально (если речь идёт о небольших, не больше 3-4 тысяч часов проектах, для больших разговор, обычно, несколько иной).

Я очень даже понимаю заказчиков, которые, увидев в живую то, что они описали в ТЗ, осознавали, что всё совершенно не так, как им хочется, и кардинально меняли большое количество функционала.

Тут важно, чтобы лидер (кстати, так и не понял, чем он в данной формулировке отличается от руководителя проектов) чётко объяснил заказчику, что возможно сделать быстро, а что займёт дополнительное время и, конечно, повлечёт дополнительные расходы со стороны заказчика. Дальше всё зависит от дипломатических способностей лидера и адекватности клиента.

Кстати, второй стороной этой медали является умение лидера успокоить команду, которая, обычно, бунтует против изменений.
>Кстати, второй стороной этой медали является умение лидера успокоить команду, которая, обычно, бунтует против изменений
Детский сад. Команду бунтующую против изменений нужно распустить.
Им платят деньги за работу.
Я выражался образно. Просто обычно происходит отторжение (иногда — неявное), люди теряют активность, производительность и постоянно задают себе вопрос: «зачем я это делаю, если всё равно переписывать придётся».
В этом смысле — понятно.
Считаю необходимым всегда своей команде толковать: «Заказчик платит — делаем любой каприз».
Результат — команда расходится, на местных форумах и в кулуарах быстро идут слухи от обиженных, что компания Х — осиное гнездо, а конкретно ПМ — редкая сволочь :)

Неважно, насколько это правда. Важна, что после этого нанимать новых людей станет сложнее. Факт.
Понятное дело. Более того, кроме того что придётся нанимать, так ещё и слаживать новоиспечёный коллектив. Но если дело доходит до «бунтов», то это единственно верное решение.
У нас это называется просто бизнес-аналитик, что, по-моему, вполне логично. Надо проанализировать бизнес заказчика, понять, что ему надо и предложить ТЗ.
Еще раз убеждаюсь как мне повезло — к мнению прислушиваются — даже кое-что реализуют.
В итоге — и почти полная свобода в реализации — и сроки за мной, и самому интересно. Главное — сделать каркас — с учетом всевозможных переделок-перекрасок стен\обоев.
А дальше — сегодня так — а завтра в зеленый цвет — да пожалуйста — еще неделю к сроку и % к оплате.
Налицо две проблемы:
— не выстроены отношения с заказчиком;
— отсутствует управление требованиями.

Аналитик вам нужен, как здесь уже отметили. Нужно стать на сторону заказчика, понять что и зачем ему нужно, и что может потребоваться в перспективе.
Поддерживаю комментатора: проблема управления требованиями налицо. Абсолютно во всех проектах, на которых я работал как бизнес/системный аналитик требования рано или поздно уходили «кто в лес, кто по дрова».
Тем не менее, разброд и шатание будут всегда, надо просто стараться их минимизировать (Коуз: «Устранить ущерб невозможно»).
IT-лидер, он как и везде. Лидер это тот, кто умеет зажечь команду, довести начатое до конца, четко видит цели и средства их достижения. Обладает мощной харизмой и чутьем. А то, о чем статья — это не о лидере, а действительно о каком-то аналитике.
> Ведь он может сам организовать свой бизнес.
Это очень сильное преувеличение, для организации бизнеса — особенно в России — требуется целый ряд других психологических качеств.
Кроме того, далеко не каждый, кто может организовать свой бизнес, хочет организовать свой бизнес.
Дело в том, что зачастую у заказчика нет умения сформулировать задачу. Чтобы сформулировать задачу нужен технический специалист, желательно с программистским прошлым, который и должен работать с таким заказчиком. Мне кажется, что требовать грамотное ТЗ у заказчика, зачастую далёкого от IT, часто безбожно.
Да у них даже желания формулировать зачастую нет. «Хочу сайт» и всё. Некоторые: «хочу сайт как вот этот и чтоб было еще это и то».
Зачастую от заказчика и не требуют указания технических подробностей. Проблема в том, что заказчик действительно не всегда знает, а зачем ему это нужно и что он хочет конкретно ( как об этом писалось выше). Если он сформулировал зачем и что, даже пусть своим языком, то это уже хорошо. То есть сначала собираются просто требования, бриф, а уже на основе этого составляется ТЗ, в составлении ТЗ заказчик может вообще не принимать участия.
И еще один момент, хорошо если заказчик описывает задачу в меру своей компетенции, а не лезет в ту область где он ничего не понимает ( где он не специалист), например архитектура приложения и дизайн.
У нас на «ИТ-лидера» привыкли всех собак вешать, по дели у без дела, то есть: ты руководитель, тебе и за все отвечать, но понятие «все» настолько расплывчато… соответственно и спроси идет даже за вещи, не относящиеся к непосредственной деятельности. Поэтому многие Итшники предпочитают быть рядовыми «строителями», то есть:
1) поставили задачу
2) выполнил
3) отчитался
4) ушел домой со спокойной совестью
Все правильно написано!
>Ответ смотрите сегодня вечером на канале ТНТ!

Хоть бы время уточнили или название передачи. У всех вечера разные могут быть (часовые пояса не забываем)
Все верно, но как-то не о чем… Я бы перенес в блог «Мысли вслух», но такого, кажется, нет.
Может быть дело в том, что в вашем примере не IT лидер, а раб-погонщик других рабов? :]
а как же user stories? полезный подход, и не только к клиентам. и клиенты любят такой «ролевой» подход (мои, не знаю за других). тут и «зачем вам это надо?», и «как это должно выглядеть?», и т.д. и т.п.
НЛО прилетело и опубликовало эту надпись здесь
«Таким образом, на современном рынке IT, больше всего затребован прораб-телепат с навыками пророковедения, способный прочитать мысли заказчика на расстоянии и предвидеть возможные изменения, чтоб изначально подойти к проекту таким образом, чтоб он был завершен в срок и удовлетворил заказчика.» — в точку!
В любом случае надо общаться с заказчиком, независимо от того работает ли «it-лидер» на зарплате или на проценте. Может дело в том — напрямую с ним общаться или через посредников?
>прораб-телепат с навыками пророковедения
надо открывать в универах новый предмет открывать!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.