Глупые мысли об IT

Привет, народ!

Не знаю, как у вас, а на моей практике самыми большими сложностями во всех проектах или просто в IT жизни, были так называемые “PPP”: people, politics and processes (люди, политика и бюрократия). Когда попадаешь на поле боя этих три “п”, можно быть увереным, что ничего хорошего из этого не выйдет. Или тебя перемолотят, пережуют и выплюнут, или, если хватило ума распознать ситуацию, можно выжить, пережив самые сложные моменты где-нибудь в сторонке :)
Чем больше растешь в должности, тем больше приходиться работать с людьми. Умение общаться и “не наступать на мозоли” людям часто выходит на первый план. Пусть даже некоторых хочется пристрелить во время работы, но коллег не выбирают :) Самый плохой вариант – кто-то выше тебя по должности сделал ошибку, но “уперся” рогом и не хочет ее признать. Я уже упоминал о такой ситуации и честно признаю, что очень мало людей могут признаться в этом и “отыграть назад”. Чем выше должность, тем труднее это сделать. Но люди, которые могут это сделать, заслуживают самого большого уважения.
Политика… это продолжение первого случая, но уже вовлечена группа людей. Ситуация ухудшается, если существуют конкурирующие группы. Гарантированы тлеющие очаги конфликтов, грозящие превратиться на время в “локальную заварушку”. Опять же, все мы люди и вполне возможно, случайно (или не случайно) можно оказаться (или быть причисленным) к одной из группировок. Надо стараться дистанцироваться от всех конфликтных ситуаций. Полностью не получиться, тогда надо на себя напяливать самую толстую шкуру, которой вы обладаете, стараться “обтекать” или получать удовольствие. КПД работы в любом случае будет низкий, как бы вы не старались.
Ну а третий вариант – когда невозмонжо что-то сделать, не потратив гораздо больше энергии на бюрократические проволочки. Систему можно попытаться сломать, но она будет сопротивляться силами паразитирующих на ней людей. Явно под бюрократию открыли должности, набрали людей и они просто так не откажутся от своих мест и зарплат. Можно попытаться найти обходные пути или лазейки. В любой неэффективной системе появятся более простые процессы, не вовлекающие сложную бюрократию. Где-то они в каких-то точках будут пересекаться, но в целом процесс будет быстрее и эффективнее. Надо знать нужных людей :) Вот и все.
А что у вас, мои немногочисленные читатели, вызывает самые большие проблемы в работе? :)

Засим раскланиваюсь,
Рустам.

Привет, народ!

Несколько раз я был в ситуациях, когда при работе над какой-либо задачей возникал рабочий конфликт интересов. Т.е. несколько заинтересованных сторон решали, как лучше сделать что либо и не могли прийти к одному общему решению. Часто это  случается, когда стороны имеют одинаковый “вес” в плане возможности принятия решений.
Особенно ярко этот конфликт проявляется при обсуждении соглашения об именах/названиях: будь то учетные записи, имена компьютеров и т.п. Не дай бог участвовать в этом! :) Религиозные войны не идут ни в какой сравнение! Или, к примеру, есть проект, в котором какую-либо задачу можно решить либо одним способом, либо другим. Если есть два мнения, предложенные конфликтующими или конкурирующими группами/людьми, эти способы будут защищаться с самым яростным юношским запалом.
Чтобы не оказаться в подобной ситуации, надо сразу определиться с главными типами людей, вовлеченных в работу над чем-либо:

Привет, народ!

В предыдущем посте я упоминал, что после того, как сформулированы требования к функционалу (Functional Requirements (FRs)) и его качественным характеристикам (Non-Functional Requirements (NFRs)), необходимо оценить, насколько качественными являются собранные или сформулированные данные. Иметь некачественные FRs/NFRs это так же плохо, как и вообще не иметь их. Рекомендуется произвести первоначальную оценку качества и полноты FRs/NFRs. Ничего нового я не расскажу тем, кто уже ознакомился с TOGAF. В любом случае, случае, я постараюсь рассказать от себя о первоначальной оценке с помощью критериев S.M.A.R.T (Specific, Measurable, Actionable, Realistic и Time bound).
В принципе, методика SMART может применяться не только в IT. Если подумать, то это просто подход с точки зрения здравого смысла. Если есть какие-то требования, надо проверить, что они:

• Конкретные (Specific)
  Если задача или требование сформулировано очень расплывчато – “сделайте мне красиво”, то можно сказать, что ничего у вас нет. Надо избегать неясных формулировок;
• Измеряемые или допускающих количественную оценку (Measurable)
  Это как-был уточнение первого требования, чтобы сделать его более конкретным, вводя количественные характеристики. Например, я столкнулся при работе над одним проектом с требованием, чтобы уменьшить время входа в систему (логина) на компьютерах под управлением Windows XP. Требование конкретное, но абсолютно невозможно понять, в чем проблема и насколько надо улучшить время входа: то ли сейчас время составляет один час, и бизнес будет счастлив уменьшить его до 45 минут, то ли время входа составляет 10 секунд и бизнес хочет добиться входа за меньше чем за секунду. Опять же, непонятно, надо ли достигнуть этого для всех пользователей, или только для тех, у кого сейчас время входа больше часа, сколько пользователей имеет такую проблему т.д. Для того, чтобы сделать требование имеющим хоть какой-нибудь смысл, оно должно было бы быть сформулировано подобным образом: уменьшить время входа, используя как цель время входа в систему эталонного пользователя с соотвествующим профилем (ссылка на максимальные, минимальные и среднее время для таких пользователей).
  Точно так же и в реальной жизни можно придумать как использовать подобный критерий. Например, можно решить купить машину. Конкретно? Конкретно. Но вот какую!? Если пойти купить какую-нибудь малолитражку для семьи из 7-ми человек, то это будет самый глупый поступок. Для улучшения первого критерия надо будет упомянуть еще хотя бы максимальное количество человек, которое будет перевозиться в такой машине; бюджет, желаемых расход, вид топлива плюс обязательные (кондиционер, к примеру) и желаемые опции (автоматическая коробка передач и т.п.). Купленная машина, руководствуясь такими критериями, скорее всего будет удовлетворять поставленным целям.
  Я думаю, каждый в жизни когда-нибудь сталкивался с подобными ситуациями: уменьшить время отклика приложения (насколько!?); улучшить “дружественность” приложения к пользователю (это как!? как это измерить!?) и т.д;
• Ясно описывающие проблему/цель (“Actionable”)
  Данный критерий позволяет убедиться, что есть понимание цели или проблемы и это позволит составить предварительный список того, что надо сделать. Иными словами, должно быть понятно, что надо будет сделать. Например, требование “увеличить производительность труда сотрудников” вряд ли можно назвать ясным. Оно должно быть переформулировано в что-то типа: “Увеличить производительность труда сотрудников путем оптимизации программного обеспечения, используемого сотрудникпми для выполнения непосредственных обязанностей. Производительность может быть достугнута перепланировкой интерфейса приложений с целью уменьшения <времени ввода данных, заполнения форм и т.п.> и повышения производительности серверных компонент приложений: <уменьшения времени отклика/уменьшения времени для получения отчетов и т.д.>;
• Требования должны быть реализуемые/достижимые (Reasonable)
  Здесь нужно подходить с позиции здравого смысла: являются ли выдвигаемые требования реалистичными или достижимыми? Если, согласно требованию, нужно построить космический корабль и приземлиться на Солнце, то при нынешнем уровне технологий такое требование не является реализуемым. Так же, как и например, требование сокращения времени загрузки компьютера до 1 сек. с момента нажатия кнопки включения :);
• Указывающие время выполнения (Time bound)
  В данном случае для выполнения данного критерия надо убедиться, что указаны временные рамки для выполнения заданых требований. Вполне возможно, что все будет сформулировано четко, ясно и недвусмысленно, но вот сроки на выполнения будут не указаны вообще (в таком случае скорее всего ожидается “мгновенное” выполнение задачи, что может быть невозможно) , или предоставляются совершенно нереалистичные сроки. К примеру: построить ракету для полета на Луну <требования и описания> и закончить постройку завтра :)

В реальной жизни при стандартных операциях или задачах многие критерии подразумеваются по умолчанию. Просьба сходить в магазин за молоком скорее всего подразумевает, что надо отправиться туда “как только так сразу”, купить то молоко и в том количестве, которое покупалось все время. Самое главное, точно знать, что все вовлеченные лица пользуются одними и теми же значениями по умолчанию.
И еще: SMART может использоваться как при проверке предъявляемых требований, так и при их предъявлении. Когда вам прийдется что-то просить сделать, не забудьте сформулировать свои требования так, чтобы другой человек проверил их по этой методике и остался доволен :)

Засим раскланиваюсь,
Рустам.