Странная штука — жизнь

11 10 2013

Как то странно всё происходит. Ещё пару дней назад я боялся даже думать про смерть. Мысли о ней вызывали сумасшедшую панику и возникало желание поскорее забить голову чем нибудь другим. А сегодня я уже подумывал о написании некролога и установки счётчика обратного отсчёта времени.
Странно, но как только я про это начал думать, чувство страха смерти уменьшилось.
В умных книгах пишут, что смирение с фактом неизбежности смерти высвобождает много энергии для жизни. Что ж, посмотрим, что из этого получится.

Реклама




Лучшее – враг хорошего

10 03 2013

Не знаю, ка вы, а я очень часто встречаю людей, которые ознакомившись с новыми технологиями, норовят применить их тут же в своей компании. И в правду – зачем обращать внимание на возможные риски, зачем анализировать влияние внедрения на бизнес процессы, зачем задумываться – кто это все будет поддерживать. А еще лучше – найти клиента и на нем опробовать, подучиться на нем же… Странно, как только по том возникает вопрос – почему это мы сорвали сроки, превысили бюджет в 2 (3, 4… подставьте свою цифру) раза и как результат – нету у кого брать отзыв о результатах работы. Казалось бы – что тут сложного – давайте для работы с базой данных будем использовать Entity Framework вместо Nhibernate. Какая разница – они делают одно и то же. Что нам с того, что много нюансов…

Порой, я за собой замечаю тенденцию использовании новшеств на проектах, очень рискованно… L Чтобы не подвести клиента, приходится впахивать. По молодости — до нескольких суток без сна и отдыха. Что сделаешь – у клиента запуск рекламной компании, вложены огромные средства. При этом страдали родные, я сам, нервничал клиент.

А как же без новшеств… Какая мотивация для сотрудников? Кто хочет работать со старыми технологиями, оставаться на старом уровне… Самостоятельное чтение книг, ресурсов, прослушивание подкастов и просмотр видео тренингов – все это очень хорошо. Но что это значит без практического подкрепления. Скопить знания через глаза и уши а не через руки, наверное, доступно очень ограниченному количеству очень талантливых людей. Мне это не под силу.

Новые технологии – риск и очень немалый. И не важно кто автор – вы, ваш менеджер или же клиент. Надо очень внимательно относиться к планированию архитектуры приложения, выбору технологических нюансов.

Для минимизации этого риска надо помнить, что может быть предвестником его возникновения. Фразы, на подобие:

  • Ребята, тут команда Microsoft новый Фреймворк выпустила, он покроет все наши потребности
  • Нам тут поставили новый экскаватор, мы вам эту траншею за 2 часа выкопаем…
  • Я хочу, чтобы мой софт работал в самых последних версиях браузеров.

Что же делать для минимизации влияния этого риска и не демотивировать сотрудников (на текущий момент уж очень они ценный ресурс, и они про это знают и всячески пытаются манипулировать…)?

Надо четко осознавать текущие скилы членов команды, их опыт (Не стоит сажать экскаваторщика, долгое время проработавшего на тракторе «Белорус» с навесным ковшом на самоходный экскаватор Volvo). Надо быть технически грамотным, чтобы понимать области пересечения технологий, их сложность. Стоит составить карту бизнес процессов и смоделировать возможные места, где новые технологии могут существенно повлиять на ход проекта. Если возможно, выделить наиболее прогрессивных сотрудников, и разработать прототипы для рискованных зон. Может где-то стоит отказаться от новой технологии в сторону старой, при это найдя дополнительные способы мотивации сотрудников (ну к примеру, разрешить 20% своего времени тратить на свои проекты, где он может «обкатать» свои знания). Группа R&D тоже может сыграть важную роль…

Дерзайте!





10 Contracts for your next Agile Software Project | Agile Software Development

26 05 2011

Может кому пригодиться:

10 Contracts for your next Agile Software Project

Источник: 10 Contracts for your next Agile Software Project | Agile Software Development.





Некоторые цитаты, относящиеся к подготовке коммерческого предложения

25 05 2011

Очень понравились некоторые цитаты из умных книг. Мне кажется, они очень даже полезны при подготовке коммерческих предложений:

«Any proposal manager (or outside consultant, for that matter) who claims to know how to run a serious proposal effort without chaos should be quietly and briskly dismissed from reality. Chaos is the very nature of the proposal beast, and the manager who accepts this fact is ready to face another one: While the chaos of proposal work cannot be eliminated, it must be controlled. Otherwise, it will eat the managers, the proposal team, and the proposal itself alive.»

  • Pugh, 1993, p. 82

«There are many ways to write proposals as there are companies, but many of these ways are crude, ineffective, expensive, and bound to repeat many previous mistakes…

We cannot stress enough that organized proposals are probably twice as likely to succeed as those ‘fly by the seat of the pants’ exercises…»

  • Whalen, 1996, p 1-3

«….managing a proposal is one of the toughest, most challenging jobs you will ever encounter. It involves dealing with a wide variety of people with conflicting interests and organizing and directing the efforts of an ad hoc collection of people with diverse talents and expertise into a cohesive, motivated team under the most adverse circumstances in an intensive activity and under great pressure to achieve a goal against which the odds of success are not favorable. Can you think of a more daunting endeavor anywhere else in the world?

  • Helgeson, 1994, p.206

«An enormous amount of time is wasted in aimless, rambling meetings replete with musings and irrelevant chatter of unfocused dilettantes intent on wasting everyone’s time while they run their mouths. I would wager that the man hours wasted every single day in the conference rooms of America would be equivalent to the number of man hours required to build the Taj Mahal.»

  • Helgeson, 1994, p. 192

«A proposal must deliver critical ideas quickly and easily. Your writing must be clear if you want others to understand your project and become excited by it. It will be hard to accomplish this if you have not clarified your thoughts in advance.»

  • Geever and McNeil, 1993, p. 17

«Developing a clear, comprehensive picture of what the client is seeking is the single most important part of your whole proposal preparation process — if you get the requirement wrong, you’ll get the solution wrong.»

  • McCann, 1995, p.53

«You ought to be writing the proposal to sell stuff. Products, services, projects, ideas. Whatever you’ve got. The proposal is a marketing tool; it helps you make money by convincing people to contract with you for the kinds of things you can provide. The proposal positions your product or service as a solution to a business problem.»

  • Sant, 1992, p. 9




Top 10 Procurement Risks — Tender Preparation — PM Hut

20 05 2011

Top 10 Procurement Risks — Tender Preparation — PM Hut.





Управление проектом через управление рисками

5 05 2011

Совсем недавно начал читать книгу «Deadline. Роман об управлении проектами» (Том ДеМарко). Не скажу, что данная книга «захватила» меня с первых страниц, как это сделала книга «Критическая цепь» (Голдратт М. Элияху), однако что-то в ней есть и останавливаться пока не собираюсь. Книга отличается от большинства технической литературы – она повествует о проблемах и способах их решений. Это роман. И этим все сказано.

Так что я хотел сказать… Заметил там фразу, невзначай брошенную одним из героев… — проектом можно управлять через управление рисками. Не знаю, как дальше будут развиваться события, однако это мысль подтверждает мои ощущения и желания.

Будем читать дальше… J





Риски при использовании новых инструментов.

28 10 2010

Надеюсь, кто-нибудь подумал над вопросами, поставленными в предыдущем посте. Если не так – очень жаль. Мои мысли и опыт – это мои мысли и опыт. Не факт что он Вам подойдёт в конкретной ситуации на конкретном проекте. Всё же лучше подумать. Ваш опыт для Вас намного ценнее опыта, описанного в книгах и тем более моего. Ниже мои мысли по поводу поставленных вопросов.

Итак. По поводу начала работы. Скорее всего (и в большинстве ситуаций, которые мне приходилось наблюдать) сценарий будет следующим:

  • Человек кратко ознакомиться с доступными материалами и очень поверхностно посмотрит на новый «инструмент» исходя из предыдущего своего опыта.
  • Скорее всего, он найдет некоторые аналогии и сделает пагубный вывод – можно использовать предыдущий опыт, методы и в новом «инструменте».
  • Произведет оценку работы и что хуже всего – выдаст оценку своему начальнику или заказчику.
  • Во время исполнения он столкнётся с фактами, которые ранее не были замечены.
  • Погрузится в изучение и потратит время
  • Реализует задачу согласно скупым знаниям о новом «инструменте» и предыдущему опыту (вот только пришла мысль, что может возникнуть вопрос – неужели предыдущий опыт не нужен? Нужен и очень важно уметь видеть его слабые и сильные стороны, критически подходить к нему и главное использовать его в нужное время, в нужном месте и с умом.)
  • А еще прибавьте то же самое для каждого члена команды. Итог – каждый делает по-своему и в силу своих возможностей. Проект – полная мешанина и в дальнейшем большие проблемы с интеграцией и качеством.
  • Ну что – время потратили, проект не реализован (ну хорошо, если реализован хотя бы с задержкой), деньги перетрачены с лихвой, клиент не доволен, потеря репутации, потеря клиента и возможных проектов от него, потеря потенциальных клиентов и как результат всего – денег и развития.
  • И при всем при этом исполнитель всегда найдет оправдание. Хорошо, если при этом клиента не назовут «последним придурком». При этом он как специалист и как человек просто отличный.

Здорово… Не так ли? Знакома ситуация? Мне так очень!

Что ж, надо определить наличие этого риска в проекте. Как это сделать? Каждый новый «инструмент» практически всегда – риск. Хорошо если есть люди, уже немного поработавшие с ним. Наверное, самый быстрый и простой способ – произвести умеренный анализ «инструмента» (а кое-где и глубокий), сформировать список возможных методов работы, сопоставить с требованиями и определить возможные проблемы. Еще проще, наверное, проконсультироваться с людьми, которые хоть немного сталкивались с этим «инструментом» и выявить возникавшие проблемы и недостатки.

Ну а теперь, в случае наличия данного риска, надо его предотвратить.

Вот мои варианты:

  • При наличии запаса времени, необходимо определить задачи, которые должны быть покрыты «инструментом», закрепить эти задачи за членами команды и выделить время для достаточно глубокого анализа возможностей «инструмента» и определить «подводные камни», затем провести совещание и поделиться полученными знаниями. Такой подход я использовал будучи менеджером одного из проектов для Tomson-Reuters на EPAMе. Ребята справились на «отлично». По-моему, это сыграло свою роль в дальнейшем развитии проекта.
  • Другой вариант – изучить, как используется «инструмент» на других компаниях (подразделениях, проектах) и просто скопировать методику. Этот пункт может использоваться в комбинации с первым подходом.
  • Для случая недостатка времени (когда проекты стартуют непредсказуемо) необходим другой подход. На Альторосе я предложил директору создать инновационную группу, которая бы отслеживала вместе с отделом маркетинга тенденции в области разработки, определяла наиболее перспективные, накапливала знания до некоторой глубины, реализовывала небольшой проект для «обкатки» знаний и в случае появления проекта из данной области человек из этой группы мог бы передать знания участникам проекта и некоторое время их сопровождать. Плюсы, я думаю, видны сразу, так же как и минусы. На сколько я знаю, такую группу на Альторосе всё же сформировали хоть и после моего ухода. Пока не знаю ничего про ее эффективность – надо разузнать J
  • Ваш вариант?

В следующий раз хочу поговорить о необходимости обязательного проведения анализа работы (review). . у и соответственно вопросы:

  1. Надо ли проводить review (кода, проекта, процессов)?
  2. Если надо, то должна ли быть официальна процедура?
  3. Связано ли review с какими-либо рисками? Если да – то, как и какими?
  4. Естественно – как определить есть ли риск?
  5. И если есть – что сделать чтобы предотвратить пагубное влияние на проект?