В теме 20 ответов, и 6 участников, последнее обновление сделано пользователем 
Николай Киреев 14 г, 4 мес. назад.
-
Сообщения
-
А как вы действуете в подобных ситуациях?
Я теперь стараюсь не допускать таких ситуаций. Для этого перед началом работ обсуждается сам процесс разработки, структурная организация проекта, какие артефакты, в какой срок, для какой цели должен представить аналитик, кто и каким образом ими будет пользоваться, где и как они будут храниться. Критерий качества работы, это когда только аналитик работает с исходными документами и взаимодействует с заказчиком, а остальные используют созданные им артефакты, при этом они легко их находят в общей структуре проекта и они им понятны без дополнительных разъяснений. Если и после совместных обсуждений команда скептически относится к идее применения UML и, в частности, Use Case-анализа в рамках своих проектов, то от такой работы следует вежливо отказаться.
Ну значит вам повезло, что на вашем жизненном пути были только такие проекты. Я лично как то больше сталкивался с нехваткой ресурсов, времени, недостаточной постановкой процессов и т.д. В таких условиях навязывать UML моделирование, наряду с другими аналитическими активностями, не представлялось возможным. И явно не потому, что не умею навязывать
. Вежливо отказываться от всех проектов (и уж, честно говоря, хотя бы от одного) тож сомнительный вариант.Aut UML, aut nihil (:
Если проектов хоть отбавляй, то, конечно, подход оправдан.
А вот если сваливается проект, который надо поставить через 3 недели, а по грубым подсчетам на разработку (только на неё) нужно недели 2-2.5 недели, а еще тестирование, стабилизация, развертывание. Причем, если не поставлять через 3 недели, то можно даже не браться (другие возьмутся). Итак, каждый день на счету. Всё равно успеем провести все подготовительные работы? Ну там сооздать и обсудить communication plan, responsibility matrix и т.д. В принципе, если они шаблонные и там за часик просто подставить специфическую для проекта инфу, то, вероятно, да. Тут, наверное, я соглашусь, что если заранее подготовиться, то можно.
Что касается критерия качества, то с теоретической точки зрения всё верно. Ну т.е. живи мы в идеальном мире, создавай мы идеальные спеки, тогда да. Хотя в идеальном мире, я думаю, заказчик с программистом и без нас быстро бы нашли общий язык (; понимаете, к чему я клоню? Как бы иногда этого не хотелось, пока что ничто не заменит живого человеческого общения. Этот факт стоит признать, т.к. проекты делают пока что люди, а не машины, а людям нужно общаться (:Я лично как то больше сталкивался с нехваткой ресурсов, времени, недостаточной постановкой процессов и т.д. В таких условиях навязывать UML моделирование, наряду с другими аналитическими активностями, не представлялось возможным. И явно не потому, что не умею навязывать .
Я тут хотел немного другую мысль выразить. Да, времени всегда не хватает, и процессы всегда не достаточно понятны, но это не может быто причиной для отказа и от UML, и даже от основных аналитических активностей в рамках RUP. Бывают команды, у которых налажены свои, пусть не оптимальные, и не совсем правильные, и далеко не вписывающиеся в стандарты процессы разработки, тем не менее, приводящие их к успеху. Я столкнулся с одной такой командой, они разрабатывают специфический промышленный софт (модернизация заводов стройиндустрии) и у них все держится на одном единственном супер-проектировщике, который все держит в своей голове.
Когда я рассказал о методах визуального моделирования и о UML их генеральному, то тому эти идеи очень понравились, но когда встал вопрос о внедрении, то команда отнеслась к идее очень скептически и, несмотря на очевидные плюсы, они не захотели изменять установившийся процесс. Вот такие случаи я и подразумевал.
А так, если хорошо заплатят, то нехватка времени меня не пугает, и я со своим ноутом и быстрым интернетом могу за несколько дней и ночей у себя в деревне на свежем воздухе очень многое сделать.
А так, я работаю как freelancer на немецких проектах, которые, бывает, нахожу сам. С немцами у меня постоянная связь по Skype.…Когда я рассказал о методах визуального моделирования и о UML их генеральному, то тому эти идеи очень понравились, но когда встал вопрос о внедрении, то команда отнеслась к идее очень скептически и, несмотря на очевидные плюсы, они не захотели изменять установившийся процесс…
Сори что вырезал фразу из контекста. Не сочтите за навязывание своего видения, я не знаю деталей реальной ситуации, но мое ощущение от краткого описания этой истории таково:
Вы продали идею генеральному, как водится в RUP-е, UML-е и все остальном "генеральном" и "основательном". Это не проблема сделать. Директорам и иже с ними всегда нравятся стройные, контролируемые, максимально документированные и умные теории. Конечно же именно генеральные платят деньги, поэтому с точки зрения заработка денег, Вы поступили стратегически верно. А вот с тактикой… Непосредственно тем, кто должен и мог бы получить основные бенефиты от внедрения средств моделирования, Вы продать идею не смогли. А зря. С них и надо было начинать. Они и есть основные потребители. Именно их проблемы и должны решаться в данном кейсе. Своего генерального они бы и сами уболтали на бабки в два счета, это самое простое что тут могло быть. Только вот продать именно тем, кому это наиболее необходимо, в данном случае, и есть наиболее сложная и важная задача. Генеральный в данном случае лишь счетная машинка, выписывающая вам чеки. =)Конечно же именно генеральные платят деньги, поэтому с точки зрения заработка денег, Вы поступили стратегически верно. А вот с тактикой… Непосредственно тем, кто должен и мог бы получить основные бенефиты от внедрения средств моделирования, Вы продать идею не смогли. А зря.
Я с Вами полностью согласен, просто с генеральным директором я очень хорошо знаком, и он часто пользуется моими услугами по контактам с немецкими фирмами, а из его команды я практически никого не знаю. Но, скоро, я буду для них сам в качестве заказчика на разработку промышленного софта, вот тогда и будем с ними вместе UML осваивать.
Вы должны авторизироваться для ответа в этой теме.
