Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
К сожалению, данные примеры не единственные, но на мой взгляд гораздо хуже, когда внедрение новой методологии, сводится к внедрению некого ПО без понимания зачем и почему внедряется методология.
В ИТ для многих компаний главное — это продать. А на сколько оно будет удовлетворять потребностям клиента уже не сильно задумываются. Также, часто бывает, что в больших системах персонал не понимает как пользоваться всеми благами и продолжает работать по старинке, т.к. боятся изучать что-то новое.
Подскажите, пожалуйста, начинающим аналитикам, каким инструментарием пользуетесь, где и как набирать опыт, какие книги стоило бы прочитать.
Подскажите, пожалуйста, начинающим аналитикам, каким инструментарием пользуетесь, где и как набирать опыт, какие книги стоило бы прочитать.
Сильно сомневаюсь что сферовакуумный аналитик смог бы решить положительно любую из описанных ситуаций. Нужен скорее не аналитик, а консультант, который понимает не только бизнес, но и средства автоматизации. А в идеале такой консультант должен еще до запуска проекта объяснить заказчику все подводные камни внедрения систем.
Бумажки типа ТЗ\ХЗ совершенно не важны для внедрения, довольно странно что отсутствие формального ТЗ выставляется как недостаток, а наличие — как преимущество.
Бумажки типа ТЗ\ХЗ совершенно не важны для внедрения, довольно странно что отсутствие формального ТЗ выставляется как недостаток, а наличие — как преимущество.
Я подозреваю, что под ТЗ автор разумеет совокупность бизнес-, функциональых и пользовательских требований к проекту, которые согласованы между заказчиком и подрядчиком. А ТЗ — это, вообще-то, внутренний документ подрядчика, с точки зрения контроля качества желателен, но, в принципе, на усмотрение подрядчика (хотя отсутствие ТЗ в крупном проекте характеризует подрядчика не лучшим образом).
>Бумажки типа ТЗ\ХЗ совершенно не важны для внедрения
В статье поясняется — нет ТЗ (т.е. зафиксированных требований, как я понимаю автора), нет гарантии. Нет гарантии — нет ответственности.
Но в общем, даже требования вторичны. Главное — «соблюдение базовых принципов этики», о чём автор тоже говорит.
>Бумажки типа ТЗ\ХЗ совершенно не важны для внедрения
В статье поясняется — нет ТЗ (т.е. зафиксированных требований, как я понимаю автора), нет гарантии. Нет гарантии — нет ответственности.
Но в общем, даже требования вторичны. Главное — «соблюдение базовых принципов этики», о чём автор тоже говорит.
«Нет ТЗ — нет гарантии» вовсе не означает «Есть ТЗ — есть гарантия». Согласовать ВСЕ требования заранее даже на маленьком проекте сложно, а на большом так и вовсе невозможно. Так что все это не более чем громкие слова.
На практике успешность проекта определяется желанием заказчика не просто закрыть проект, а получить измеримые результаты. Собственно при наличии измеримые результатов все остальные вещи уходят на второй план. А для полного успеха у исполнителя также должно быть стремление достичь результатов за наименьшее количество денег.
На практике успешность проекта определяется желанием заказчика не просто закрыть проект, а получить измеримые результаты. Собственно при наличии измеримые результатов все остальные вещи уходят на второй план. А для полного успеха у исполнителя также должно быть стремление достичь результатов за наименьшее количество денег.
«Нет ТЗ — нет гарантии» вовсе не означает «Есть ТЗ — есть гарантия».
Вы правы отчасти, в том смысле, что это не 100% гарантия. Однако наличие прописанных и согласованных требований — это инструмент, который, во-первых, позволяет придти к общему пониманию, что вообще нужно, и тем самым уменьшить риск возникновения ситуаций, описанных в статье. Во-вторых, это и некоторый инструмент давления на подрядчика, по крайней мере если он дорожит своей репутацией.
Согласовать ВСЕ требования заранее даже на маленьком проекте сложно
Это не означает, что нужно вообще отказаться от согласования требований и их фиксации.
Заказчики, они как дети — им нельзя говорить «ты — дурак» или «у тебя всё плохо». Сначало надо показать вкусные ништяки, а уже потом способ их достижения.
По теме статьи — нужна грамотная аналитика. С акторами, юзкейсами, сценариями. А уж потом — архитектура и ТЗ.
По теме статьи — нужна грамотная аналитика. С акторами, юзкейсами, сценариями. А уж потом — архитектура и ТЗ.
Вообще никому не стоит говорить «ты — дурак», особенно если ты с этим человеком бизнес хочешь делать. «Вкусные ништяки» не нужны если они не решают проблемы. Поэтому показывать как раз надо проблемы, но не в стиле «у тебя все плохо», а «смотри, у XYZ все было как у тебя, а потом стало лучше потому что они начали использовать ABC».
Наличие проектной документации — это всегда больше преимущество, чем недостаток. К сожалению, бывает документация, которую как раз можно больше отнести именно к «недостаткам», а в договорной базе отсутствуют даже минимальные требования к оформлению, содержанию и используемым нотациям. Гарантийные обязательства — вопрос комплексный, который должен быть предусмотрен и на уровне договора, и на уровне документации, так как иначе будет непонятно, на что именно эти самые обязательства распространяются.
«Ты — дурак» — концепция проигрышная, поэтому лучше не судить, а аргументированно демонстрировать конкретные проблемы с четкими показателями: «производительность ниже отраслевых нормативов на 40%», «не соблюдается техника безопасности при выполнении таких-то операций», и сразу давать варианты решений. После внедрения выбранного варианта, как раз появляется возможность сказать и про ABC, и про XYZ, на уровне точных замеров «до» и «после».
«Сферовакуумные аналитики» — это, к сожалению, бич нашего времени. Проверить их, правда, весьма легко: достаточно спросить при первом же общении, какие они видят варианты решения тех или иных задач. «Сферовакуумные» обычно рассказывают о том, что «неоднократно это делали», «без проблем решаем», и льют воду. Профессионалы «демонстрацию силы» не упустят.
«Ты — дурак» — концепция проигрышная, поэтому лучше не судить, а аргументированно демонстрировать конкретные проблемы с четкими показателями: «производительность ниже отраслевых нормативов на 40%», «не соблюдается техника безопасности при выполнении таких-то операций», и сразу давать варианты решений. После внедрения выбранного варианта, как раз появляется возможность сказать и про ABC, и про XYZ, на уровне точных замеров «до» и «после».
«Сферовакуумные аналитики» — это, к сожалению, бич нашего времени. Проверить их, правда, весьма легко: достаточно спросить при первом же общении, какие они видят варианты решения тех или иных задач. «Сферовакуумные» обычно рассказывают о том, что «неоднократно это делали», «без проблем решаем», и льют воду. Профессионалы «демонстрацию силы» не упустят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация и/или результат?