Сообщения

Сообщения за Апрель, 2012

:)

Коллеги,

это последний стул в КАБА. Проект не взлетел (он не стал для нас местом для общения), держать его отдельно выделенным инстансом нет ни времени, ни смысла.

Мне нравится фейсбук, я буду там: https://www.facebook.com/skalinov

Тем более Гриша давно мне предлагал это сделать :)

Пара теорий, проверенных на собственном опыте

Процессный подход позволяет делать проекты более слабой командой

В теории да, на практике приходится сталкиваться с серьезным психологическим ограничением. Суть его в том, что можно заставить человека работать по процедуре, но если он не понимает ее смысла, то к ее выполнению будет относиться формально (еще хуже – тупо забивать), а менеджера будет считать самодуром. Бороться с этим бессмысленно, поскольку в таком понимании ситуации этот человек абсолютно искренен. Поэтому его отношение к процедуре – это уже вопрос веры. Разъяснить важность и необходимость тоже особо не получится, поскольку тут дело в уровне профессиональной зрелости (в той ее части, которая отвечает за осознанность использования навыков).

Моделирование против документирования - кто круче?

Честно скажу, что понятия не имею, к какому выводу и как приду в этой заметке. Но очень хочется в этом вопросе поставить точку. Грамотные люди скажут, что это холивар, а я, соглашаясь, отвечу так: ну и что? К какому-нибудь выводу, да придем. Итак...
Документ пишется текстом, который можно прочитать. Никаких нотаций при этом знать не надо, любой, даже неквалифицированный в IT человек сможет понять, что автор документа хотел донести. А если не сможет понять, то документ можно переписать так, чтобы даже гномики поняли ценность изложенной в нем мысли. С моделью все иначе. Чтобы ее прочитать, нужно знать нотацию. Причем не просто знать, а уметь на ней читать - т.е. знать в совершенстве. Представьте себе девушку, работающую в кредитном отделе и в совершенстве знающую ARIS или UML. Представили? Да? Не, я серьезно. И что она, по вашему, там делает??? Выходит, документирование круче.

Недорешения

Одной из больных тем #swp12 для меня лично стала тема принятия решений. В общем-то люди говорят правильные вещи. Причем не могу сказать, что для меня свершилось открытие. Но точно могу сказать, что в ряде очень важных моментах я не решился на те решения, которые могли бы кардинально изменить ситуацию, но либо доставили бы кому-нибудь боль, либо шли бы в разрез с какой-нибудь внутренней политикой.

Под половинчатыми решениями я понимаю решения, на момент принятия которых есть совершенно четкое понимание, что их реализация не приведет к достижению тех целей, которые необходимо достичь.

Не знаю, есть ли в природе какая-нибудь классификация половинчатых решений, но для себя я их разделяю на следующие категории:
решения, которые на самом деле не решения - т.е. достижение цели отпускается на самотек, а там уж куда кривая Гаусса вынесет;решения, при принятии которых в первую очередь приходится ориентироваться на какие-то внутренние политические моменты, а уж во вторую - на те цели, которые до…

Про IT-подразделение Заказчика

Кто бы там чего не говорил про Бизнес, подразделения Заказчика и прочие организационные вещи, мы ведь все равно знаем, что для нас, вендоров, Заказчиком нашей работы является IT-подразделение. И успех наших проектов определяется не только усердием и квалификацией наших людей, но и тем, что из себя представляют IT-ники на стороне автоматизируемого Бизнеса. Вот о них и предлагаю пообщаться.

Три ключевые функции IT-подразделения:
Интеграционная - обеспечивать интегрированную инфраструктуру (в широком смысле - развитие, работоспособность, соответствие потребностям Бизнеса и т.п.) автоматизации основных видов деятельности компании.Креативная - обеспечивать Бизнес идеями автоматизации, способствующей активно развивать Бизнес.Коммуникационная - являться интерфейсом между ключевыми лицами (как внутренними, так и внешними), заинтересованными в решении IT-задач компании.