Project management (rus)

Удобная доска для записей (Online)

Да ещё многопользовательская и бесплатная (но за 5$ её можно сделать ещё круче). Ссылка: http://corkboard.me

Advertisements
Standard
Project management (rus), Requirement management (rus)

Как сделать текст «прозрачным»?

… Какой аналитик не хочет, чтобы его тексты воспринимались легко и образно, как картинки? Один мой коллега часто сравнивает текст со стеклом. Через чистое стекло человек сразу увидит всё, что происходит за ним; ему не нужно пытаться смотреть под другим углом и домысливать то, чего совсем не видно. Точно также и с текстом — если он написан понятно, читатель с первого раза правильно поймёт мысль автора, и ему не нужно будет перечитывать отдельные фразы и домысливать то, что не ясно…

Статья: Как сделать текст «прозрачным»?.

Standard
Project management (rus)

Оценка реализуемости проекта (юмор)

Программист – начальнику отдела

Мы не можем справиться с предложенным проектом! Повторяю: HЕ МОЖЕМ! Это
потребует полного изменения структуры дерева наследования, никто в нашем
отделе в ней не разбирается. Более того, никто в компании не знает даже
языка,
на котором это всё было написано, так что даже есликто-то и захочет этим
заняться, он просто не сможет. Если Вас интересует моё мнение, наша компания
вообще не должна соглашаться работать над подобными проектами.

Hачальник отдела – руководителю проекта

Проект потребует изменения структуры системы. Hа текущий момент у нас нет
сотрудников, имеющих опыт подобной работы. К тому же, язык нам не очень
знаком,
так что нам придётся организовать кое-какую переподготовку, если
мы возьмёмся за этот проект. Если Вас интересует моё мнение, мы не готовы
работать над проектами подобного рода.

Руководитель проекта – менеджеру среднего звена

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

Менеджер среднего звена – менеджеру верхнего уровня

Этот проект подразумевает пересмотр структуры. У нас есть несколько
специалистов, которые работали в этой области и ещё несколько специалистов
по языку реализации. Они могли бы организовать обучение персонала. Если Вас
интересует моё мнение, нам стоит взяться за этот проект, но действовать
нужно осторожно.

Менеджер верхнего уровня – управляющему

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

Управляющий – клиенту

Это как раз тот тип проектов, в которых наша компания специализируется.
Мы уже завершили несколько проектов подобного типа для крупных заказчиков.
Поверьте, что в этой области именно мы являемся наиболее компетентными.
Если Вас интересует моё мнение, мы можем выполнитьэтот проект успешно и в
назначенные Вами сроки.

Источник: uml2.ru

Standard
Project management (rus)

Решение проблем

Последние вести из-за той стороны океана – наиболее модная штука это Problem solving, но пока с айтишной заточкой ничего не нашел, попалась разве что такая штука – Problem_solving_en.

Может кто встречал что-то ичсто айтишное по данной тематике?

Standard
Project management (rus)

Windows Azure и облака.

На swp’11 ещё давали в раздатке маленькую книгу по Windows Azure, наконец-то добрался и до нее. Но так как лень сканировать – приведу небольшую статью для начинающих, которая помогла мне получить первичный набор знаний про облака (самый первичный).

История

Первые идеи, косвенно  соотносящиеся с тем, что мы сегодня понимаем под облачными вычислениями,  и описывающие возможность вычислений с использованием удаленных вычислительных центров, относятся еще к 70-м — 80-м годам. Однако публичная история собственно cloud computing в  современной реализации начинается примерно с 2006 года. Именно тогда не  нуждающаяся в представлении компания Amazon представила свою инфраструктуру  веб-сервисов (Web Services), обеспечивающую не только хостинг, но и  предоставляющую клиенту удаленные вычислительные мощности. Вслед за Amazon  аналогичные сервисы представили Google, Sun и IBM. А в 2008 году свои планы в  этой области озвучила компания Microsoft. Причем Microsoft анонсировала не  просто сервис, но полноценную облачную операционную систему Windows Azure (о  ней мы еще поговорим).

На первый взгляд, Microsoft не удалось обогнать своих конкурентов по облачной сфере — официальный релиз Windows Azure состоялся лишь в начале 2010 года. Тем не менее, на сегодняшний день Windows Azure остается одним из самых крупных и всеохватных проектов в сфере cloud computing. Но 2010 год можно считать важной датой в истории облачных технологий не только из-за релиза Azure, но и благодаря появлению ряда облачных сервисов, ориентированных уже не на разработчиков, а на простых пользователей. И именно на примере одного такого сервиса мы попробуем объяснить суть концепции cloud computing.

Концепция cloud computing: взгляд со стороны  пользователя

17 июля в США был  запущен облачный сервис OnLive, предоставляющий возможность играть в  современные игры даже на самом простом оборудовании. Технически это выглядит  следующим образом: сама игра располагается на удаленном сервере и там же  производится обработка графики, которая на компьютер конечному пользователю  поступает уже в «готовом» виде. Проще говоря, те вычисления, которые при  обычной игре на компьютере выполняют видеокарта и процессор, здесь уже  выполнены на сервере, а ваш компьютер используется лишь как монитор. Можно и  вовсе использовать обычный телевизор, только придется к нему прикупить  миниатюрную приставку OnLive MicroСonsole, которая и будет связующим звеном  между пользователем, сервисом и отображающим устройством.

 Собственно, в этой  информации уже скрывается ответ на вопрос «что же такое облачные вычисления».  Облачные вычисления — это новая парадигма, предполагающая распределенную и удаленную обработку и хранение данных. Облако (раньше это слово мы писали с кавычками, но за последние два года оно  так распространилось именно в своем компьютерном значении, что можно его  использовать уже как термин, а не как метафору) — это не что иное, как некий  крупный дата-центр (или сеть взаимосвязанных между собой серверов). В случае с OnLive именно в этом дата-центре хранятся файлы (в данном случае —  игры), и именно там совершаются все вычислительные операции. Что это значит?  Это значит, что автоматически снимаются все проблемы с производительностью  компьютера и количеством свободного места на винчестере. Кроме того, отпадает  необходимость платить довольно большие деньги сразу за продукт, который вам не  обязательно придется по душе. Не секрет, что большинство игр не хочется  проходить повторно, поэтому получается, что стоимость нескольких часов (или  пусть даже нескольких дней) удовольствия — неоправданно высока. Куда удобней  был бы вариант, при котором вы платили бы только за то время, которое играете.  Или же (если такой вариант вам психологически неудобен) — вы бы платили некую  небольшую фиксированную сумму ежемесячно, что позволяло бы вам играть без  ограничений в любые из доступных игр. Именно это и предлагает OnLive.

Еще один игровой сервис, который также предоставляет богатую интернет-функциональность и имеет отношение к облачным технологиям — Xbox Live (в России он будет запущен 10 ноября). Суть сервиса в том, что обладатели приставок Xbox 360 и КПК на базе Windows Phone 7 могут играть друг с другом в компьютерные игры и общаться, а также покупать новые игры, адд-оны и различный мультимедийный контент в онлайн-магазине. Таким образом, Xbox Live создает некую виртуальную вселенную для геймеров, компоненты которой расположены не на консолях конечных пользователей, а в облаке. Однако, в отличие от OnLive, Xbox Live не предполагает (по крайней мере, пока) обработку аудиовизуального контента, снимающую необходимость приобретения консоли/КПК.

Но главное — и тот, и другой сервисы предлагают нам игры как услугу. А теперь представим,  что речь идет не об играх, а о программном обеспечении. То есть вы платите не  за продукт как таковой (грубо говоря, за коробку с диском), а за конкретные  функции/возможности, которые вам предоставляет данный продукт. И здесь мы подошли  еще к одному ключевому понятию из сферы облачных технологий: Software as a Service  (ПО как сервис, сокращенно — SaaS).

Software as a Service

Согласно SaaS-концепции вы платите не единовременно, покупая продукт, а как бы  берете его в аренду. Причем, используете ровно те функции, которые вам нужны  (и, соответственно, платите за них же). Например, раз в год вам нужна некая  программа. И чаще вы ее использовать не собираетесь. Так зачем же покупать  продукт, который будет у вас лежать без дела? И зачем тратить на него место (в  квартире, если это коробка с диском, на винчестере, если это файл)? Здесь,  конечно, можно возразить, что программы, которые мы используем изредка, как  правило, имеют небольшой размер и цену, и их легче купить один раз, потом уже  об этом не думая об этом. А если онлайн-сервис (предоставляющий полные  функциональные возможности этой программы) бесплатный? Уже можно задуматься! Именно по такому пути пошли два конкурента — Microsoft и Google.  Обе компании выпустили наборы сервисов, позволяющих работать с документами. У Google это Google Docs, у Microsoft — Office Web Apps.

При этом, оба сервиса тесно взаимосвязаны с почтой (Gmail в первом случае и Hotmail во втором) и файловыми хранилищами. Таким образом, пользователя как бы переводят из привычной ему оффлайн-среды в онлайн. Важно, что и Google, и Microsoft интегрируют поддержку своих онлайн-сервисов во все программные среды — как настольные, так и мобильные (напомним, что Google создала ОС Android, а Microsoft — Windows Phone 7).

Аналогичную концепцию (но с несколько другими акцентами) продвигает и главный конкурент обеих компаний — Apple. Речь идет об очень любопытном  сервисе под названием MobileMe (подробнее о нем читайте здесь). Сервис включает в себя почтовый клиент,  календарь, адресную книгу, файловое хранилище, альбом фотографий и инструмент  для обнаружения утерянного iPhone. За  возможность пользоваться всем этим Apple берет примерно 65 евро (или 100  долларов) в год. На первый взгляд, за что деньги-то платить?  Почтовые онлайн-сервисы существуют и  существовали прежде. Но главное здесь — другое. Apple обеспечивает такой  уровень взаимодействия своего набора интернет-сервисов и приложений на  компьютере (под управлением Mac OS X), телефоне, плеере и iPad (все – под  управлением iOS), что необходимость в использовании браузера пропадает. Вы  пользуетесь привычными программами на своем Mac, iPhone и iPad, однако, все  данные хранятся не на них, а в облаке, что позволяет забыть о необходимости  синхронизации, а также — о доступности (наверняка многим владельцам КПК знакома  ситуация, когда вы вбили новый контакт в адресную книгу на компьютере, а потом  забыли перенести на КПК, и в итоге в нужный момент контакта под рукой не  оказалось). При этом, оговоримся, не обязательно использовать именно приложения  — можно и просто через браузер с любого компьютера зайти в свой аккаунт.

Если Apple интегрирует веб-сервисы в привычные приложения операционной системы, то Google заходит с противоположной стороны: разрабатываемая интернет-гигантом операционная система Chrome OS представляет собой, фактически, один браузер, через который пользователь взаимодействует с разветвленной сетью веб-сервисов. ОС ориентирована на нетбуки, отмечаются очень низкие системные требования и отсутствие необходимости самостоятельной установки программ (так как все программы работают непосредственно в вебе). То есть Google предоставляет преимущества облачной концепции, обычно декламируемые при работе с корпоративными клиентами, обычным пользователям. Вместе с тем, очевидна невозможность использования таких нетбуков в странах с недостаточно широким проникновением широкополосного интернета. Потому что без интернета нетбук на базе Chrome OS будет совершенно бесполезен.

Microsoft пока чуть более осторожна в этой сфере. Основные продукты Microsoft для частных клиентов — Windows и Office — пока еще сохраняют привычную схему работы и распространяются по традиционной модели. Однако, Microsoft довольно активно начинает предлагать свои корпоративные продукты по облачной модели Software as a Service.

Ну а в центре всей облачной инфраструктуры Microsoft — операционная система Windows Azure. Windows Azure создает единую среду, включающую облачные  аналоги серверных продуктов Microsoft (реляционная база данных SQL Azure,  являющаяся аналогом SQL Server, а также Exchange Online, SharePoint Online и Microsoft  Dynamics CRM Online) и инструменты разработки (.NET Framework и Visual  Studio, оснащенная в версии 2010 года набором Windows Azure Tools). Так, например,  программист, создающий сайт в Visual Studio 2010, может не выходя из приложения  разместить свой сайт в Windows Azure.

Чем же может быть полезно облако бизнесу? Какой смысл использовать облачные варианты привычных приложений на уровне предприятия?

Pay  as you go

Представьте, что вы  захотели открыть свой бизнес и создать какой-то сайт. Купили  сервер, наняли IT-сотрудника, запустили свой сайт… Поначалу посетителей  немного, и сервер справляется с нагрузкой, но затем сайт рекламирует известный  блоггер, количество посетителей резко увеличивается, и вам приходится срочно  покупать новые серверы. А следовательно — покупать программное обеспечение,  нанимать сотрудников, искать дополнительные помещения и так далее. В общем, расходы  взлетают до небес. Но вот количество посетителей стабилизируется, и  оказывается, что серверы работают в среднем на 10-15 процентов своих  возможностей. Лишь изредка количество посетителей возрастает настолько, чтобы  загрузить серверы достаточно сильно. А иногда даже бывает, что серверы  оказываются перегружены — и тогда ваши посетители начинают испытывать сложности  общения с сайтом. Как же решить эту проблему? Воспользоваться возможностями  облачных технологий. Вы можете разместить сайт в облаке, и оплачивать вам придется лишь те мощности,  которые будут реально задействованы, тот трафик, который будет реально создан.  Это убережет вас от необходимости приобретения  дополнительного оборудования в случае пиковых нагрузок и одновременно избавит  от проблем с повседневным обслуживанием многочисленных серверов. Чем это  отличается от обычного хостинга? Тем, что помимо физического размещения и  поддержки вашего сайта вам еще предоставляют необходимый софт (который также  расположен в облаке), масштабируемость и бесконечные возможности для  расширения.

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

Собственно говоря,  мы привели лишь пару частных примеров. Если же говорить глобально, то все варианты  облачных технологий подразумевают подписочную модель оплаты. Причем, не только  в отношении софта, но и по части аппаратных ресурсов. И это условно называется Pay  as you go. Ну а тем, кому аппаратные ресурсы не нужны, могут просто взять требуемые приложения в аренду (и здесь мы возвращаемся к понятию Software as a Service).

Применимо к корпоративным нуждам, аренда приложений дает следующие преимущества:

  • Низкие первоначальные инвестиции в ИТ (не нужно покупать  оборудование, ПО, платить за установку и настройку решения);
  • Оптимизация расходов (оплата ежемесячно по факту  использования);
  • Снижение рисков (лицензии на ПО не надо ставить на  баланс, то есть нет ответственности, сервис-провайдер несет ответственность за  бесперебойную работу услуги);
  • Масштабируемость решений (можно легко увеличивать и  уменьшать количество пользователей, добавлять новые решения)
  • Простота поддержки (оплачивается единая IT-услуга, в  состав которой все включено; не надо заботиться о стандартизации ПО, обучении  сотрудников IT новым версиям и т.д.)

Приведем высказывание Николая Прянишникова, президента российского отделения Microsoft: «Благодаря облаку IT становится услугой. Это выгодно всем. Компаниям, которые могут значительно сократить расходы на IT, сконцентрировав высвободившиеся ресурсы на развитии собственного бизнеса, и частично перевести капитальные расходы в операционные (кроме того, компании малого и среднего бизнеса получают дополнительные преимущества от использования недоступных ранее корпоративных IT-технологий). Рынку IT и телеком, способствуя возникновению новых бизнес-моделей и стимулируя появление стартапов. И, как следствие, государству и обществу: повышается уровень информатизации страны и развитие экономики получает дополнительный стимул».

Представители компаний, использующих облачные технологии, соглашаются с Microsoft. «Наряду с повышением производительности и эффективности на всех уровнях – как в офисе, так и при удаленной работе, – мы получили решение, которое может расти вместе с нашей компанией и расширяться в соответствии с нуждами бизнеса. Данное решение очень удачно вписывается в наш бизнес-план. Чтобы установить в компании Microsoft Exchange Server, обычно требуется несколько недель, а то и месяцев, начиная с момента покупки лицензий и серверов до запуска в эксплуатацию. Также необходим собственный штат IT-специалистов для его установки и обслуживания. А мы получили решение немедленно и по низкому месячному тарифу» — говорит президент компании Организация времени Глеб Архангельский.

Взгляд в будущее

Несмотря на  очевидные преимущества, саму концепцию облачных технологий немало критикуют,  причем с самых разных сторон. Главные претензии связаны с безопасностью  (достаточно ли надежно защищены данные в облаке? И нет ли вероятности того, что  сам владелец дата-центра решит воспользоваться доверенными ему данными?) и  жизненной необходимостью надежного широкополосного доступа в интернет. Мы  сейчас не будем увязать в полемике, тем более что эти моменты действительно не  так уж и очевидны. Однако, несмотря на все сомнения будущее облачных технологий  представляется самым радужным. Доказательством того, что это не временное  увлечение, а новый путь развития высоких технологий, является следующий факт:  сколь бы ни были сильны противоречия между тремя гигантами — Microsoft, Apple и  Google, сколь бы ни различались взгляды их руководителей и идеологов на  развитие индустрии и потребности пользователей, практически одновременно они  вошли на эту новую (пока что) территорию, и совершенно не собираются оттуда  уходить. Более того, именно с облачными технологиями все три компании связывают  свое будущее. И пусть Microsoft об этом трубит на каждом углу, а Apple,  наоборот, не делает громких заявлений и держит в тайне свои планы (среди которых,  в частности, называют создание облачного варианта iTunes), однако, дела говорят  сами за себя. Еще два года назад концепция cloud computing казалась лишь  красивой идеей, «маниловщиной», странным экспериментом. Сегодня же преимущества  облачных технологий могут почувствовать даже те люди, которые не связаны с  разработкой программ, веб-технологиями и прочими узкоспециализированными вещами  (вышеупомянутые Xbox Live, Windows Live, MobileMe, OnLive, Google Docs — яркие тому примеры). А что  будет завтра? Об этом, возможно, нам как раз и собирается рассказать Стив  Баллмер! Не пропустите!

Standard
Project management (rus), Requirement management (rus)

ЛАФ11. Я. Могут ли быть выгодны ошибки аналитика или история одного тендера

На основании данной статьи я готовил свое выступление на ЛАФ’11.

 Введение. Мы все ошибаемся

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

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

Любопытно следующее – со временем выяснилось, что ошибки могут повлечь за собой не только отрицательные, но и положительные последствия и принести компании прибыль. Каким образом? Об этом и пойдёт речь в настоящей статье.

Предпосылки ошибок и ответственные за них. Тендеры и прибыль

Итак, если аналитик ошибся, то его ошибки зафиксированы в Техническом задании или постановке на реализацию (так как, если говорить о ГОСТе, это конечные документы, на основании которых ведется разработка). Но, возвращаясь к анализу источников ошибок и ответственных за них, хочется задать вопрос: только ли аналитик виноват в том, что эти ошибки возникли? Я считаю, что нет, и предпосылки для ошибок возникают в самом начале проекта, при попытке компании выиграть тендер. Замечу, что под ошибками я не подразумеваю риски, так как риск это то, о чем мы знаем.с

На всякий случай поясню:

● Тендер – (от англ. tender – торги, конкурс) прямое заимствование из английского языка, используемое для обозначения торгов, конкурсов.

Существует открытый и закрытый вид тендера. При открытом тендере участие в конкурсе могут принимать любые желающие. Закрытый тендер подразумевает ограниченный круг участников.

● Компания хочет заказать систему, автоматизирующую некоторый вид ее деятельности. Она объявляет тендер, на который обычно откликается несколько компаний, предлагающих различные условия работы (например, по срокам, стоимостям). В итоге заказчик выбирает одну компанию, условия которой были наиболее выгодными. Эта компания – победитель тендера.

Второй пункт уже неявно говорит о том, что победит компания, лучшая по следующей совокупности: известность / надежность – цена – сроки. Стремясь выиграть конкурс, компании существенно уменьшают занижают сроки реализации и стоимость проектов, что не может не сказаться на качестве работы, в том числе, аналитиков. В связи с этим, компаниям – участникам тендера, можно дать следующие рекомендации:

1. Участвуйте в тендерах.

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

2. Выбирайте конкурс или аукцион в соответствии со своими финансовыми возможностями.

Здесь следует обратить внимание на два момента. Первый из них – хватит ли у нас финансов, чтобы закончить проект. Например, оплата проекта производится после приемки системы, плюс к дате закрытия контракта добавляется ещё 60 дней (не знаю, чем это вызвано, но это распространенная практика). То есть, может получиться так, что мы в течении года вели разработку, потом у нас было 2 месяца просрочки (в течении которых мы выплачивали оговоренные пени), а потом компания ждала ещё 60 дней до получения денежных средств. Не следует отбрасывать вариант того, что проект вообще провалится через пол года, так как заказчик выставит нереализуемые требования, которые, тем не менее, не будут противоречить Технико-коммерческому предложению (ТКП), вынесенному на тендер. Самым простым примером может быть доработка существующего продукта – запросы на изменения от заказчика могут быть не реализуемы в рамках архитектуры системы.

Любопытный случай из практики. Запрос на изменение иногда может выглядеть несколько необычно, например: пользователь должен силой разума переносить файлы в архив. В итоге, достаточно было реализовать кнопку “Перенести в архив”.

Второй момент – нужно оценивать стоимостные предложения конкурентов и внимательно оценивать не уйдёт ли компания в убыток по итогам проекта.

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

4. Если вам незаконно отказано в участии или праве исполнения контракта, смело подавайте жалобу в ФАС (Федеральная антимонопольная служба), не забыв при этом указать в ней все необходимые сведения.

В представленном выше списке наиболее интересны пункты 2 и 3 – они наиболее сильно влияли на работу аналитика, так как компания начинает резко уменьшать сроки реализации и стоимость проекта, обещая реализовать качественную систему.

Категории компаний, участвующих в тендере

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

● Неинтересные компании – обычно на слуху у профессионалов в ИТ сфере, имеют большой авторитет и связи в среде заказчика. Они многочисленны, с большим оборотом, надёжны, опытны и располагают бюджетом на покрытие рисков. Само собой, это всё условности, и компания может не обладать всеми перечисленными параметрами, но качество документации в них ожидаемо выше, чем в остальных компаниях. Подобные компании я назову Фаворитами.

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

Здесь необходимо добавить новое ограничение: речь идет не о проекте из 5 табличек в базе данных (то есть, мы говорим не о маленьком проекте).

Очевидно, что Наглецы могут конкурировать с Фаворитами только за счёт бюджетов и сроков, как правило, нереальных (что нередко сказывается на качестве системы), что и является наиболее распространенным фактором ошибок аналитиков.

Введу некоторую величину N, отражающую степень «наглости» компании при проведении тендера и колеблющуюся в промежутке от 0 до 1 (чем ниже N – тем наглее компания). Получаем, что при фиксированном качестве Итоговые сроки = Заложенные в тендере сроки *N, Итоговая стоимость = Заложенная в тендере стоимость *N.

Казалось бы, причём тут мы, аналитики, если за успешность проекта, в целом, отвечает его руководитель? Ответ следующий:

1. Писать ТЗ по формуле Время на написание ТЗ=Реальные сроки*N приходится нам. Для аналитика величина N отражает количество его переработок, которое потребуется, чтобы написать ТЗ в срок. Таким образом, N отражает снижение величины премии аналитиков, но чем выше N, тем выше вероятность выиграть тендер.

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

3.Прибавим сюда наём сторонних разработчиков (субподрядчиков) и “зелёных” студентов, чтобы как-то компенсировать уменьшение бюджета проекта. Например, рассмотрим некоторую абстрактную ситуацию:

В день мы можем потратить на разработчиков 1800 рублей (возьму несколько абстрактные цифры). Использовать своих разработчиков нам не по карману, каждый из них требует 300 р/час и их потребуется двое. Если нанимать субподрядчиков, то это будет 200 р/час, то есть Затраты за день = 2*8*200 =3200 руб. Нанимаем студентов за 50 р/час, обещаем им практику и рекомендации, в случае успешно выполненной работы, в итоге получаем 2*8*50=800 рублей в день, а, для надежности нанимаем своего разработчика в качестве консультанта на 2 часа в день 2*300=600 рублей. Следовательно, мы получаем 400 рублей прибыли в день. Ситуация тут следующая – ошибаются как аналитики, так и разработчики, но опытный разработчик может обнаружить некоторые ошибки аналитика, да и сам по себе ошибается реже.

4.Из пункта выше вытекает новая проблема аналитика – ему придётся больше времени тратить на функциональное тестирование по той причине, что отдельно выделенных тестировщиков может просто не быть. Или он один и не справляется. Иногда, например, аналитику быстрее будет проверить работу функционала самому, чем объяснять это тестировщикам (особенно, если требование плохо задокументированно). То есть N на нас повлияла и здесь.

Следствие. На чем сэкономили и что получили в итоге

Что же мы видим в итоге? Зачастую картина такова: проект пора сдавать, а он готов лишь на (100*N)%, а может и (100*N/2).

Ответ на вопрос «Что делать?» также вполне ясен – уговорить сдать основной функционал в срок, а потом дописывать систему (следует отметить, что это является распространенной практикой и у Фаворитов). Но, по мере снижения ошибок «system error» и повышения ошибок «Это не то, что я задумывал, это не поддерживает мой бизнес процесс!», на свет появляются ошибки написанного ТЗ, а именно:

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

2. У аналитиков не было времени нумеровать и трассировать все требования между собой и, как результат, один и тот же функционал, описанный в разных местах, противоречит друг другу.

3. Прототип противоречит текстовому описанию, а текстовое описание – прототипу. Дополнительно может возникнуть противоречие действующему законодательству – очень важный момент, так как ни в одном документе не указано, что система должна соответствовать ТЗ, не учитывая изменения в законодательстве.

И это лишь несколько проблем, из тех, что могут возникнуть.

Далее руководство поднимает вопрос «кто виноват?» – обычно это аналитик, или, из вежливости перед сотрудником, заказчик. Хотя руководство чаще всего понимает, что всему виной пресловутое N, но признавая данный факт, руководитель берёт ответственность на себя, а это происходит крайне редко. Как бы то ни было, время идёт, проект выходит за рамки бюджета, выплаты сдвигаются, заказчик начинает предъявлять претензии, в том числе финансового характера. В подобных случаях на проект пытаются перевести дополнительные ресурсы (что, впрочем, не исправляет ситуации), ошибки, противоречия в ТЗ всё так же пытаются сдвинуть на поддержку и т.д.

Исключение. Когда ошибки могут принести пользу?

Итак, мы к главному вопросу: могут ли допущенные ошибки быть полезными и хотя бы иногда помогать компании? Ответ – да, в следующих случаях:

1. Заказчик решит доработать систему. Учитывая, что заказать доработку у другого подрядчика будет достаточно тяжело – придётся разбирать, проектную документацию, которая может не отличаться корректностью, да ещё и быть дополненной перепиской аналитика и заказчика по почте. Здесь ошибки/недочёты аналитиков, в условиях ограниченного времени на упорядочивание требований, могут сыграть на руку той компании, которая изначально вела разработку. Я не рассматриваю вариант, что ошибок было слишком много, чтобы заказчик не хотел видеть кампанию победителем тендера, а так же то, что ошибки были заложены специально. Лично я пока о таком не слышал. То есть следствием будет то, что заказчик, если все-таки решится дорабатывать систему, никуда не денется.

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

Здесь возникают новые ограничения, связанные с обнаружением заказчиком ошибок в ТЗ:

1. Заказчик их не заметил до подписания ТЗ.

2. Заказчик их заметил, но не смог доказать, что это требование просто в ТЗ двояко трактовалось, а аналитик реализовал на своё усмотрение.

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

4. Заказчик не передумал с вами работать.

5. Заказчик имеет деньги на необходимые доработки.

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

Вывод. Не следует преднамеренно ошибаться

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

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

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

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

Standard
Project management (rus)

Сайт поиска профессиональных знакомств. Идея.

Сейчас можно увидеть множество сайтов текущих проф. знакомств. Например, LinkedIn или Мой круг. В них мы зачастую ищем уже знакомых нам людей и радостно с ними дружим.

Есть сайты знакомств – мы ищем себе пару, как правило, по определенным критериям, встречаемся, радостно дружим или даже женимся.

А вот некоего гибрида (самих проф знакомств и некоего поиска для этих проф знакомств) я не вижу… Рассмотрю абстрактную ситуацию: например, мне нужен QA, от которого мне хотелось бы перенять некоторый опыт. Некий QA хочет прокачаться в анализе, ну или понять что к чему – ему интересно пообщаться с аналитиком. Как бы нам вот найтись… Но такого сервиса проф. знакомств я пока не видел, хотя был бы в этом заинтересован.

То есть – я пишу свою профессию, указываю круг профессий, с кем бы мне было интересно пообщаться (или ничего не указываю и так же радостно дружу, как в МК или LinkedIn),указываю, готов ли я сам делится опытом.Поиск осуществляю по профессии, указывая, например, опыт и тп. Результат – я нахожу QA, QA находит меня и все рады.

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

Так что воть… Яндекс.Пробки на мой пост с предложениями по доработкам ответили, попробую написать куда-нибудь по поводу Моего Круга.

Standard