КаБа

Коллеги, это последний стул в КАБА. Проект не взлетел (он не стал для нас местом для общения), держать его отдельно выделенным инстансом нет ни времени, ни смысла. Мне нравится фейсбук, я буду там: https://www.facebook.com/skalinov Тем более Гриша давно мне предлагал это сделать :)

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

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

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

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