IT-Project Management

IT-PM: Персональный блог об управлении IT-проектами

Баг с публикацией поста. 408 Request Time-out

leave a comment »

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

В чем заключается проблема: при попытке публикации поста, сервер возвращает ошибку:

408 Request Time-out.This request takes too long to process, it is timed out by the server. If it should not be timed out, please contact administrator of this web site to increase 'Connection Timeout'.

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

Поборол я эту ошибку следующим образом. Открыл черновик поста, переименовал пост, озаглавив одним словом без знаков препинания. Затем, сохранил как черновик и потом опубликовал. После публикации вернул старое название.

Теперь все работает. Можно приступать к следующим статьям!

Written by Артур К.

Февраль 25, 2008 at 17:00

Опубликовано в IT-PM

Требования — это главное и основное. Часть 2: Документирование

leave a comment »

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

Все требования желательно хранить централизовано. Если требования разбросаны по множеству документов, папок, сайтов и т.д., одно из них (или целая группа) будут неучтены. Желательно строго определить формат изложения требований и придерживаться этого формата. Посоветуйтесь со всей командой. Каждый ее участник может привнести в разрабатываемый шаблон требований что-то действительно нужное.

Чтобы не записывать все требования сплошным списком, нужно выделить группы требований. Здесь каждый решает сам, какая таксономия будет удобнее. Можно взять одну из уже существующих систем классификации, можно придумать свою, «заточенную» под конкретные нужды и цели. Лично я, предпочитаю широко известную модель FURPS+. Пару слов об этой модели.

Модель FURPS+ достаточно универсальна, и вместе с тем достаточно удобна. Путаница с распределением требований по группам возникает редко. Выделяются следующие группы требований:

  • Функциональные требования – функциональность, свойства, возможности, безопасность, и т.д.
  • Требования надежности – частота сбоев, возможность восстановления, предсказуемость поведения.
  • Требования производительности – время отклика, точность, доступность, использование ресурсов.
  • Возможность поддержки и конфигурирования – адаптивность, соответствие стандартам, возможность конфигурирования.
  • Требования к реализации – требования к ресурсам, языки и средства разработки, аппаратное обеспечение.
  • Требования к интерфейсам – ограничения, накладываемые необходимостью взаимодействия с внешними системами.
  • Управление системой – требования к инструментам управления системой, к интерфейсам управления и пользовательскому интерфейсу.
  • Требования удобства и эргономики – человеческий фактор, справочная система, документация.
  • Юридические вопросы – авторское право, использование компонентов сторонних разработчиков и пр.

Также полезно снабдить требования некоторыми атрибутами. Например:

  • Уникальный идентификатор, состоящий из первой буквы названия класса требований (Ф — функциональные, Н — надежность) и целого числа. Нумерация списков в Word может сместиться в случае перемещения требования или добавлении нового, а такой идентификатор (записанный простым текстом) никуда не денется. При ссылке на требование из другого документа достаточно указать этот идентификатор.
  • Актуальность («Действительно», «Снято», «Под вопросом») — часть требований в процессе разработки снимается, но не следует сразу удалять их. Возможно, кто-то ссылался на них из других документов.
  • Источник требования — документ, либо лицо, выдвинувшее данное требование. Если требование сформулирован плохо, или непонятно откуда взялось, можно будет уточнить, обратившись к источнику.
  • Дата введения требования.
  • Проектирование — когда и кем требование было учтено при проектировании, и в каком проектном документе можно найти решение, подтверждающее, что требование учтено.
  • Реализация — когда и кем требование было реализовано, и в каком модуле/файле/документе можно найти реализацию этого требования.
  • Тестирование — когда и кем была проверена и подтверждена корректность реализации требования. Также может быть указан использовавшийся при проверке Test-Case.

Written by Артур К.

Февраль 25, 2008 at 16:33

Опубликовано в Опыт управления

Tagged with ,

Требования — это главное и основное. Часть 1: Сбор требований

leave a comment »

О том какую роль играют требования в процессе разработки написано очень много. Но раз уж я решил затронуть эту тему, придется и мне присоединится и добавить кое-что от себя.

В любом проекте, если речь не идет о чем-нибудь очень простом, фигурируют такие документы как техническое задание (ТЗ), технические условия (ТУ), требования к изделию и т.д. От названия документа и формата изложения смысл содержимого не меняется — все эти документы содержат требования к разрабатываемому продукту. Невыполнение этих требований может привести к самым разным последствиям. Самый удачный вариант — заказчик просто не заметит отсутствие тех или иных свойств изделия. Самый скверный — откажется платить деньги на основании невыполнения того же пресловутого ТЗ. Это было вступление. Теперь по делу…

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

Источники требований

1. Требования могут быть сформулированы четко и ясно в каком-то документе (те же ТЗ и ТУ). С такими требованиями работать проще всего. Они, как правило, конкретны, четки и исключительно по делу. Иногда такие требования нуждаются в уточнении. К примеру, из требования «Передаваемые по сети данные должны шифроваться» непонятно, шифровать только значимые данные, или и служебные тоже.

2. Требования могут быть высказаны заказчиком в ходе обсуждения проекта. Искусство понять, что конкретно хочет получить заказчик – это тема отдельной статьи. Заказчик в большинстве случаев сам не знает, что конкретно ему нужно. Часто высказывает противоречивые или плохо сформулированные требования. Самое важное, на мой взгляд, стараться говорить с заказчиком на «его языке». Если он не программист не надо пытаться читать ему лекцию на тему «Managed code vs. native code». Может ему вообще неважно, на каком языке будет написан продукт. Углубляться в эту тему здесь я не буду. Замечу лишь, что у заказчика, еще на самых начальных этапах разработки полезно бывает поинтересоваться, насколько критично то, или иное требование. Это поможет спланировать реализацию функций разрабатываемого продукта от важных к менее важным.

3. Требования могут быть обусловлены характером изделия. Например, 24 кадра в секунду минимум для видеоплеера – это достаточно очевидно. Кстати, сомневаюсь насчет необходимости учета наиболее очевидных требований. В дальнейшем это лишь отвлечет разработчиков от действительно важных требований.

В общем случае невозможно определить все требования с самого начала. Перечисленные источники – это лишь то, к чему можно обратиться на начальных стадиях разработки. Источником новых требований может стать любой документ (не говоря уже о переменчивых желаниях заказчика). По завершении некоторых задач, полезно просматривать результаты работ на предмет новых требований. К примеру, в том проекте, на котором я сейчас занят, требования собирались из следующих источников: ТЗ, модель доступа, предполагаемая архитектура, обсуждения проекта с заказчиком, use-case`ы, некоторые стандарты и ГОСТы. Больше чем уверен, что позже, с появлением новых результатов, этот список расширится.

Written by Артур К.

Февраль 13, 2008 at 22:11

Опубликовано в Опыт управления

Tagged with ,

Сделай сам! …или доверься коллеге

leave a comment »

На днях я столкнулся с такой проблемой:

Я решал очень важную и срочную задачу, и, неожиданно, появилась еще одна, которую нужно было сделать также срочно. В моем распоряжении был один свободный человек. Я прикинул, что у него решение этой задачи займет целый день (а может и больше). Я же, объективно, управлюсь часа за 3. Я уже знал, что нужно делать и представлял в деталях как это сделать. Но как быть с первой задачей? Ее тоже нужно сделать как можно быстрее!

В итоге, я отложил решение первой задачи, и принялся за вторую. Что, в общем-то, было большой ошибкой. Если бы я продолжил, я не успел бы завершить в срок ни первую, ни вторую задачу.

От ошибки меня спас мой руководитель. Он увидел, чем я занят и объяснил, что будет хорошо, если я сделаю хотя бы свою работу. А то, чем я занимаюсь сейчас — делаю не свою работу.

Позже по пути домой я задался вопросом: «Как определить какая работа моя, а какая нет?» Нет, на этот вопрос я не ответил. Но вечером я решил для себя следующее:

Если мне кажется, что я могу сделать что-то быстрее и лучше чем мой коллега, то:

  1. Я могу ошибаться. В действительности у коллеги получится быстрее и лучше.
  2. Даже если я прав, я не смогу всегда выполнять сам все то, что у меня получается лучше.
  3. Пока коллега не научится решать задачи такого рода, он будет решать их медленно и некачественно. А он не научится, пока я буду пытаться делать все сам.

Следовательно, когда Вы передаете сложные и необычные задачи своим подчиненным или коллегам, это идет «в плюс» и им и Вам. Они со временем повышают свою квалификацию. Вы получаете больше времени для решения своих задач.

Written by Артур К.

Февраль 10, 2008 at 20:12

Опубликовано в Опыт управления

Голый энтузиазм, как стартовая мотивация

leave a comment »

Для того чтобы сотрудники работали с максимальной самоотдачей им нужна мотивация. Это известный факт. Одна из задач руководителя – максимально мотивировать свою команду, сделать так, чтобы люди хотели делать то, что от них требуется. Факт №2: наибольшая составляющая этой самой мотивации – заработная плата. Факт №3 – работник очень редко доволен своей зарплатой. Какой вывод? Правильно, человека нужно мотивировать всеми прочими доступными способами.

Начало любого проекта сопровождается множеством споров и идей по поводу его реализации. С чем это связано? Энтузиазм. IT-шники в большинстве своем энтузиасты. Я сам занимался и занимаюсь программированием и знаю не понаслышке, что процесс выработки концептуальной модели продукта приносит намного большее удовольствие, чем все остальные работы по проекту. У человека масса идеи и ему хочется воплотить их в жизнь. Это нормальная потребность в самовыражении. Философы называют эту потребность созидать инстинктом либидо (в противоположность потребности разрушать – мортидо).

Если Вы, как руководитель проекта (или член команды разработки) будете стремиться всеми силами этот энтузиазм в людях поддержать и преумножить, то это уже должно стать достаточной на первое время мотивировкой. И если не для всей команды, то для большей ее части точно.

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

В продолжении поста я привожу пример из личной практики. Читать далее…

Written by Артур К.

Февраль 10, 2008 at 15:28

Опубликовано в Опыт управления

Start-up

leave a comment »

Это модное сегодня слово применяют, как правило, для обозначения всего нового, что мы можем найти в глобальной сети. Будь то новый Web-2.0 сервис или же просто еще один поисковик, все это принято называть Start-up. Что ж, этот блог не является исключением, отсюда и название поста.

Предыстория блога

В фирме, где я работаю, начало нового календарного года всегда означает начало, по крайней мере, одного нового проекта. В этом году таких проектов было два. И руководителем одного из них (вдруг!) назначили меня. До этого я был программистом, а затем числился аналитиком. Это назначение стало для меня полной неожиданностью, тем более что моих обязанностей и полномочий мне ни кто не объяснил. Просто потребовали результат. С тех пор меня не покидает ощущение, что я все делаю неправильно. Это в теории кажется легко (мне тоже казалось). «Дайте мне хорошую команду, и мы вместе горы свернем!» — скажете Вы, если Вам еще не поручали долгосрочных проектов. Смею вас уверить, менеджмент – это далеко не такая простая вещь, как может показаться.

Если Вам еще не надоело читать, загляните на страничку «О Блоге». Там изложены все задачи и цели этого блога. Надеюсь, что из этой затеи получится хоть что-нибудь дельное, потому как я очень не люблю делать что-то впустую. Итак, приступим?

Written by Артур К.

Февраль 10, 2008 at 13:37

Опубликовано в IT-PM