Мы тут с Анастасией Лихницкой посовещались и предлагаем (Анастасия предлагает) открыть новую тему (см. заголовок).

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

Кому интересна предыстория, посмотрите [ссылка] - это начало дискуссии на эту тему.

Ждем-с :-))

Дамы и господа!

Как и обещал, готовлю материал по менджменту в аутсорсинге. По ходу дела просматириваю другие материалы. Вот интересные ссылки.

[ссылка]
[ссылка]

Глазин Константин

1 июня в Питере проводится Первая в России международная конференция по оффшорному программированию. Подробно на [ссылка]

Комментарии на [ссылка]

Об участниках:
К настоящему времени подтвердили свое участие в Конференции такие известные лица в мире информационных технологий (ИТ), как советник вице-президента США г-жа Эстер Дайсон, бывший вице-президент компании «ИБМ» г-н Роберт Вильямс, Президент Совета по программному обеспечению и Интернету из Массачусетса г-жа Джойс Плоткин, Президент Ассоциации ИТ Юго-восточной Азии г-н Казу Адачи (Япония), исполнительный директор общегерманской Ассоциации ИТ г-н Ульрих Щнайдер и многие другие.

Андрей!

А Вы, случаем, не собираетесь обобщить материалы "Об информационных, управленческих и бизнес-технологиях в российских коммерческих предприятиях"?

Было бы очень интересно почитать.

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

Андрей!

Я все время с интересом посматриваю на Ваши форумы. Так и подмывает погрузиться в дискуссию. Я это обязательно сделаю, как только закончу этот форум - уж очень мне интересны затронутые Вами темы.

Дело в том, что я 6-й год подряд создаю информационную систему в компании, в которой работаю (не один конечно, - я руковожу одним из направлений). Компанию нашу трудно отнести к небольшим - более 90 филиалов и более 200 представительств не позволяют этого сделать Естественно проблемы, с которыми мы сталкиваемся, отражают специфику компании: ориентированность на массовые услуги, территориальная распределенность, большое количество клиентов, необходимость консолидации деятельности различных подразделений и т.д. Дело усложняется еще и тем, что компания является учредителем и основной движущей силой холдинговой структуры, которая включает не намного меньшие компании.

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

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

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

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

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

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

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

С уважением,
Константин Глазин

Если Вы напишете статью по проблемам аутсорсинга - с интересом прочту. Особенно постараюсь вычитать: проблема-как решали-что в итоге получилось-выводы на будущее. Заранее жду

Константин, я думаю, что разница заключается вот в чем:
Холдинг с 290 удаленными подразделениями, скорее всего, довольно сильно децентрализован с точки зрения управления. По той модели управления, которую я описывал на своем форуме это - небольшой, но "аналитически" квалифицированный центр оперативного управления и 290 локальных центров управления (или их аналогов, действующих, в основном по Вашей методологии управления), большинство информационных и материальных потоков которых не должно проходить через главный Центр. Поэтому, "Ваша" модель управления сильно отличается от описанной мной, ориентированной на гораздо более централизованные структуры.
Ваше замечание принимаю: мне надо говорить не только о размерах предприятий, для которых подходит описанная мной технология управления, но и о степени централизации самого процесса управления. Впрочем, там в дискуссии я об этом уже кому-то отвечал :-).
Теперь о Вашей статье:
Во-первых, Анастасия примет участие "после работы" :-).
Во вторых, попробуйте по мэйлу позвать "Вашего третьего друга". Я, правда, особо не вдвался - кто там из Вас что предлагал и кто на что способен, но думаю, Вам можно попробовать персонально подключить необходимых людей.
Я же, в свою очередь, обещаю попытаться подключить в конце своей, а может быть и нашей совместной работы еще квалифицированных экспертов по управлению.
В-третьих, зачастую работа в одиночку дает не хуже результаты, но гораздо быстрее :-).
В-четвертых, я все-таки остаюсь с Вами, хоть и на некоторой дистанции (т.к. всех женщин - не перецелуешь, всех статей - не напишешь :-)).
Удачи !

Коллеги!

Вам не кажется, что мы уж очень сильно откланились от темы дискуссии? Давайте возвращаться в основное русло!

Андрей Аллахвердов предложил нам написать статью на обсуждаемую тему, я подготовил материалы конференции и свою их обработку в формате WORD. Кому нужны могу выслать.

Если кто хочет присоединиться к написанию статьи, почитайте топики "УВАЖАЕМЫЕ ДАМА И ГОСПОДА :-). ЕСТЬ ПРЕДЛОЖЕНИЕ", "Ну что начнем" и "Замечания по ст. "Менеджмент в аутсорсинге".

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

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

Назвать можно так "Этиология менеджмента" или "Рационализм и эмпиризм в менеджменте", нравится?

А что проще - научить программиста менеджменту или менеджера программированию? - одинаково трудно!

-

Так и я о том же!

Но только мне кажется что "…ни одна бизнес-школа не гарантирует, что за уплаченные деньги сделает человека талантливым" или "…Так продолжалось долго, ровно до тех пор, пока те же самые акционеры не пригласили нового СЕО" или «…Есть менеджеры хорошие и не очень хорошие. Это не зависит от отрасли» значительно больше относятся к общим вопросам менеджмента, чем к менеджменту в аутсорсинге!

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

По-моему этот форум фактически уже есть - это "Эффективность применения высоких технологий в бизнесе".
К тому же Наталия Моисенкова обещала такой форум с микросекунды на микросекунду :-).
Анастасия, а когда же Вы наконе-то примите участие в работе по завершению инициированной Вами же (если я не заблуждаюсь) дискусии "Менеджмент в аутсорсинге" ? Мы с Константином уже заждались :-)).

Честно говоря, по-моему действительно форумом по АйТи как раз является нынешний форум. Откроются форумы по другим специализациям.
Если Вы хотите открыть новую тему в рамках этой темы, почему бы Вам, Анастасия, просто не завести ее в этом форуме?

У нынешнего форума весьма невразумительное название. Мы здесь обсуждаем не "Эффективность применения IT в бизнесе", а скорей наоброт "Эффективность стандартных бизнес-моделей в АйТи". Топики типа "Какая польза от Интернета в бизнесе" вряд ли заинтересуют специалистов, это из области "Интернет для чайников". Если уж создатели сайта задались целью создать сообщество, то разумно было бы это сообщество объединять по интересам, иначе сообщество разваливается. Почему специалист должен просматривать все форумы, если его интересует информация по своей специальности? А это должно следовать из названия форума. Нынешние форумы вообще не структурированы, понятное дело, они были первыми. Но теперь уже опыт некоторый накоплен, можно бы изменения вносить. Это в большей мере вопрос юзабилити - сделать навигацию проще.

"Анастасия, а когда же Вы наконе-то примите участие в работе по завершению инициированной Вами же (если я не заблуждаюсь) дискусии "Менеджмент в аутсорсинге" ? "

Когда рабочий день закончится:)

-

Поскольку, пришлось второй раз писать ответ (из-за неверной оценки результата сбоя), то приведу и его полностью (думаю, избыточность поможет правильней понять мысль):
Да, Константин, несомненно. Я как раз и планировал обобщить весь свой материал на основе дискуссий на моем форуме.
Но там работа еще далека до завершения, к тому же я пытался подключить рук. сайта для анализа одного из вопросов, но там пока тишина, что несколько задерживает темпы. Зато, я пока тут с Вами набираюсь и Вашего опыта.
Для тех, кто не знает, эта дискуссия проходит на моем личном форуме по адресу: [ссылка] активная - ТЕМА 2, приглашаю всех специалистов поучаствовать.
Там я запущу еще несколько тем, а после этого попробую обобщить материал и опубликовать его здесь же на сайте.
Если Вы подумали о каком-то объединении Вашей дискуссии с моими статьями, то - наврядли. Это разные ниши. Я бы не хотел говорить "обо всем на свете". Моя тематика - говоря простым языком - точные, четко формализованные методы управления предприятием. Такая методика годится только для выше-средних и крупных предприятий - там где нити управления очень трудно удержать в головах.
У Вас же в аутсорсинге разработки - оптимальней, видимо, совершенно другая методология управления, основанная на интуиции, личных контактах, возможностью более глубокой мотивации персонала, невысоким количеством уровней иерархии и т.д.
Так что я бы не стал это замешивать в одну кучу.
Но поставить их рядом - можно было бы.
Для этого, впрочем, надо закончить работу.
А некоторые (не будем показывать на них пальцами) ее еще и не начинали :-)))).

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

Дискуссия должна быть открытой.

Дамы и господа!

Мне понравилась идея Андрея Аллахвердова написать по материалам форума совместную статью. Предлагаю всем желающим присоединиться к ее написанию.

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

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

Заранее оговорюсь, хоть компания, описанная мной в форуме, реально существует, я к ней не имею никакого отношения, так что наша совместная работа не станет для меня бесплатной консультацией.

Итак предлагаю такой план статьи (давайте пока условно назовем ее "Менеджмент в аутсорсинге"):

1. Организация маркетинга в аутсорсинге.
2. Организация взаимодействия с клиентом.
3. Управление проектом: организационные структуры и процедуры управления.
4. Управление проектными рисками.
5. HR: какие люди нам нужны?

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


Далее привожу свою обработку форума.

ОСНОВНЫЕ ТЕМЫ ДИСКУССИИ

1) Взаимодействие с клиентом
2) Менеджмент, организация проекта и человеческий фактор
3) Управление рисками
4) Путь самурая и путь камикадзе или роль личности в истории

ВЗАИМОДЕЙСТВИЕ С КЛИЕНТОМ

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

Взаимодействие с клиентом разделяется как минимум на две слабосвязанные ветви:
1) продажа
2) согласование реализации проекта

К сожалению, процесс продажи, т.е. организация того самого foreign office, который будет поставлять заказы разработчикам затронут нами лишь поверхностно. Может быть потому, что мы еще не дошли до обсуждения этой проблемы, а может быть потому, что просто упустили ее из вида. Я полагаю, что на самом деле, маркетинговая составляющая играет если и не определяющую, то уж, по крайней мере, очень существенную роль в организации аутсорсингового бизнеса. Вопросы управления проектами, рисками, организацией и даже автоматизации управления мы обсудили, но то как, собственно говоря, создать спрос на все это даже не затронули. Мы полагали, что - цитирую себя - "Сейлз, а точнее маркетинг, свою работу уже сделал. Теперь идет проект, и контакт с меркетерами минимален".

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

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

Различия в организации взаимодействия с клиентом касаются, в основном, размеров проекта.

Для небольшого проекта необходимо выделить специального Product manager (в разных репликах, он назывался по разному - Project manager, Product manager, Account manager - но его функции по большей части совпадали). В функции такого менеджера должно входить: общение с клиентом, коммуникации между заказчиком и проектной группой, управление ожиданиями заказчика, разработка и поддержка бизнес-контекста проекта.
Совмещение функций этого менеджера с функциями продажи недопустимо "… Нельзя объять необъятное, потом редко кто совмещает талант продавца и знания и умения руководителя команды …" (Анастасия Лихницкая).

Для большого проекта структура управления несколько усложняется, но происходит это за счет разделения функций нашего Product manager между несколькими ролями, а именно: project sponsor, account manager, project manager, project manager of subproject, business & requirements analyst (Борис Федотов).

МЕНЕДЖМЕНТ, ОРГАНИЗАЦИЯ ПРОЕКТА И ЧЕЛОВЕЧЕСКИЙ ФАКТОР

Основная тема в обсуждении, особенно обсуждались три направления: "Менеджмент в аутсорсинге", "Путь самурая и путь камикадзе", и "Управление рисками".

МЕНЕДЖМЕНТ

Я описал довольно типичную, на мой взгляд, ситуацию, когда молодая российская компания выходит на рынок аутсорсинга, перечислив ряд типичных проблем такой компании:

1) Основана и контролируется техническими специалистами
2) Регулярный менеджмент не поставлен
3) Организационная структура не определена -генеральный директор (он же основатель компании) управляет всем
4) Полностью отсутствует управленческий учет
5) Основные функции бухгалтерского учета - сокрытие доходов и отмазывание перед инспекторами
6) Очень сильная команда разработчиков
7) Основная масса разработчиков ориентирована на творчество, а не на конкретный результат
8) К менеджерам разработчики относятся как к нахлебникам, зарабатывающим чужим трудом

Борис Федоров справедливо заметил, что " … в такой ситуации не все зависит от руководителя проекта …" и предложил вариант решения, предусматривающий разделение управленческих ролей и выделение роли, ответственной за организацию адекватных задаче внутренних процедур и структур. Его мнение сильно перекликается с мнением Анастасии Лихницкой, которая предложила пойти еще дальше и предложила радикальный вариант. Цитирую Анастасию "Полностью отделиться от старой структуры. То есть реорганизовать разработчиков, по возможности назначить тим-лидеров из их числа, это сгладит конфликт меду менеджерами и разработчиками, построить структуру, о которой тут уже говорилось, причем желательно посадить их вместе в одной комнате, так чтобы развитие проекта было бы абсолютно прозрачно для всех участников, тогда не появятся обвинения в нахлебничестве. Да и поддерживать порядок в замкнутом пространстве легче. По мере расширения проекта привлекать либо старый состав, который уже не сможет сопротивляться новым порядкам, либо заменять новыми людьми. Во всяком случае первая задача - отсечь всё, что может мешать работать, какается ли это бухгалтерии, менеджмента или режима работы. В конце концов, найти какое-нибудь занятие людям, которое, по вашему мнению, могут тормозить процесс. Пока они поймут, что произошло, будет уже поздно".

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

Анастасия Лихницкая рассказала о своем опыте участия в проекте, где применялся PM "… к сожалению, неудачный из-за нелепого его использования. Точнее, проджект менеджер требовал КАЖДОЕ действие заносить как задание. В результате, если требовалось узнать имя файла или фолдера, надо было писать задачу сотруднику - ответить на вопрос…". А еще противоположная проблема "…менеджеры, особенно пришедшие из других областей, категорически отказываются от составления документации, постановки задач и планирования…". Сошлись на том, что методика не виновата, любую методику можно довести до абсурда, в любой системе роковую роль играет человеческий фактор, а менеджеры отказывающиеся от составления документации нам не нужны.

Александр Зубков справедливо заметил, что не в каждом проекте применимы сложные стандарты - "… ISO … не нужен средней компании-разработчику, а уж тем более начинающей … Об ISO можно говорить уже на высоком уровне, при участии в серьезных проектах…", а в принципе, "… можно все и в WORDе на бумажках делать…"

Я предложил основные принципы организации проекта и проектной группы для некрупных проектов:

Принципы организации проекта:

1) управление рисками и их планирование;
2) выпуск промежуточных версий;
3) планирование деятельности;
4) четко обозначенные контрольные точки проекта;
5) проектные группы небольшой численности.

Принципы организации проектной группы:

1) взаимозависимые и взаимосвязанные роли в малой группе;
2) определение роли, особой миссии и зоны ответственности для каждого члена проектной группы;
3) распределенные управление проектом и ответственность;
4) каждый сфокусирован на успехе проекта и настроен на работу в течение всего цикла проекта;
5) коммуникации между членами проектной группы являются ключевым фактором успеха;
6) пользователи и обучающий персонал включены в проектную группу;
7) параллельная работа всех участников группы над проектом.

На взгляд Бориса Федотова вариант менеджмента следует выбирать в зависимости от размера компании, наличия или отсутствия стандартных управленческих процедур в ней и сложности проекта.
По его мнению "… проекты стоимостью от 500К внедрение которых занимает сроки в среднем 6 месяцев удобно вести по схеме Sales -> Project manager + Account manager. PM и AM занимаются разными проблемами. Причем в общении с заказчиком наличие двух людей бывает иногда очень полезным. Здесь можно играть в разные "игры". Правда, мне показалось, что Борис хотел сказать до 500К, а не от 500К.

По-поводу структуры, то в большой компании (>200-250 человек связанных с процессом разработки) она как правило такова:

1. project sponsor (top manager)
2. account manager
3. project manager
4. project manager of subproject(s)
5. business & requirements analyst(s)
6. program manager(s)
7. team lead(s)
8. developer(s)
9. tester(s)
10. documentator(s) "

Далее перешли к управлению рисками.

УПРАВЛЕНИЕ РИСКАМИ

"Отсутствие постановки задачи или ее нечеткость - один из рисков проекта по разработке чего угодно (софта в том числе)".
Борис Федотов указал на необходимость использования стандартных методик управления рисками и составления risk report, а "…то что кто-то не считает это своим делом, просто говорит либо о лени, либо о квалификации".
Далее он сослался на методику PMI, а Эдуард Москвин подсказал методику, учитывающую, в том числе, и управление проектными рисками - это методика компании Rational - RUP.

ПУТЬ САМУРАЯ И ПУТЬ КАМИКАДЗЕ

Основной вопрос - " …что надо сделать, чтобы сделать успешный бизнес в программировании …" (Анастасия Лихницкая), какова роль человека - бизнесмена и менеджера - и его личности и идей?

Анастасия высказала здравую мысль - "…Не слишком ли много внимания уделяется формальным процессам, в то время как совершенно забыто о самом главном - в основе успешного проекта стоит хорошая идея … Остался ли вообще хоть какой-то творческий потенциал или весь этот славный топ-менеджмент погряз в создании громоздких бюрократических структур, работающих сами на себя?". Этот вопрос породил самую большую ветвь в нашей дискуссии.

Вопрос не праздный, мы действительно можем сколько угодно выстраивать управленческие процедуры, планировать организацию, писать бюджеты и т.д., но в основе любой деятельности, все-таки лежит воля человека, его мысль и творчество. Почему есть Бил Гейтс, Тед Тернер, был Джон Рокфеллер - это на западе, но есть и наши - Михаил Ходорковский, Борис Нуралиев, Андрей Казьмин, масштаб деятельности конечно у всех разный, но талант предпринимателя и менеджера на лицо. Вместе с тем, сколько безвестных Василиев Пупкиных канули в лету, так и не сумев воплотить идею в бизнес? Почему все так происходит?

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

Сошлись на том, что создание бизнеса, воплощение в жизнь идеи и управление этим бизнесом, вещи разные. И делать их должны разные люди. Есть, конечно, исключения, но они, как всегда, лишь подтверждают правило. Юрий Ткачев выразил мысль, что высший менеджер должен обладать некоторыми качествами предпринимателя, иначе " … у него могут возникнуть проблемы с управлением и развитием … бизнеса". Я с ним тут же согласился, лишь дополнив, что их основные функции различаются, что вовсе не исключает того, что управленец должен обладать качествами предпринимателя.

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

Анастасия!

Было бы, конечно, неплохо. Но, как Вы полагаете, станет ли WH делать отдельные форумы для всех отраслей, представленных в нашей экономике?

Но нам-то нужно:)

Как раз этим сейчас занимаемся! Сегодня уже должны появиться первые специализированные форумы.

А уж внутри форума делать темы по рекрутингу, например, и т.д. Впрочем, участники сами уже решат.

1. По плану статьи:
>>>" 3. Управление проектом: организационные структуры и процедуры управления."
Я думаю, что п. 3 надо вынести на 1 место, т.к. вопросы управления, все-таки являются первичными для любого вида деятельности.
2. По организации работы:
>>>"Предлагаю желающим все-таки взять на себя подготовку обзорных материалов по маркетингу аутсорсинга для нашей статьи, тогда она получится более полной."
Я думаю, что сейчас нужно обработать и опубликовать только обсужденные к наст. моменту материалы. А вопрос маркетинга (а может быть и еще какие-то вопросы) и дискусси по ним отложить на более поздний срок и дать их затем второй частью большой темы. - Примерно так, как это сделали другие члены Сообщества (не будем в суе показывать на них пальцами :-)).
3. По ряду ключевых (с моих позиций и опыта) моментов:
>>>"Сошлись на том, что методика не виновата, любую методику можно довести до абсурда, в любой системе роковую роль играет человеческий фактор, а менеджеры отказывающиеся от составления документации нам не нужны."
Совершенно верно! Голосую за каждое слово этой фразы.
Еще: у Вас прозвучала, по моему мнению очень важная фраза о том, что речь в этих дискуссиях идет, в основном, о некрупных проектах и предприятиях. Именно ! О средних же и крупных писал, в частности, я в своем личном форуме.
>>>"Сошлись на том, что создание бизнеса, воплощение в жизнь идеи и управление этим бизнесом, вещи разные. И делать их должны разные люди."
Абсолютно согласен ! Это разные специальности.

Андрей!

Вопрос первичности занимает умы человечества уже не одно тысячелетие!
На самом деле, мне кажется, что в том контексте, в котором велась беседа, а именно – организация малого аутсорсового бизнеса, не совсем корректно рассматривать вопросы управления, как первичные.

Поясню свою мысль. Если мы имеем отлаженную машину для бизнеса, на вход которой поступают некоторые рыночные объекты, а на выходе получается продукт, удовлетворяющий заданным параметрам, то для нее можно смело констатировать первичность управления. Примером такой машины, несомненно, являются крупные западные корпорации – производители ПО. Но и Coca-cola тоже не маленькая компания и имеет четкий и отлаженный механизм управления. Можно ли утверждать, что этого достаточно для успешного ведения информационного бизнеса? По меньшей мере - сомнительно. Как минимум, важен вопрос специализации рассматриваемой машины или классификации объектов управления.

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

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

Согласны?

С уважением,
Константин Глазин.

Дело в том, что любой объект "...необходимо создавать исходя из вполне конкретных целей...".
Вообще любая работа должна начинаться с целеполагания (лучше в письменном виде).
После этого нам сразу станет ясно, что сначала надо наладить взаимодействие с маркетологами (а это - часть функции управления), а только потом заниматься самим маркетингом.
Ну и "раз уж я упал в погреб", то выскажу еще одну мысль. Я ее вчера упустил.
>>>"По-поводу структуры, то в большой компании (>200-250 человек связанных с процессом разработки) она как правило такова:..."
Дело в том, что для разных по размеру проектов и фирм состав этой структуры может быть совершенно разным в том плане, что один человек может совмещать несколько функций, или наоборот, для одной функции будет неск. человек. Поэтому корректней говорить не о структуре, а о выполняемых функциях, т.е. о функциональной модели.
Да, и еще. Перечень "типичных проблем начинающей компании" мне очень понравился :-).

Ну да, вполне с Вами согласен. Я, в общем-то, и хотел сказать о том, что сначала необходимо разобраться с целями "... лучше в письменном виде ...", а потом уж проектировать структуру и функции управления. А уж "... заниматься самим маркетингом ...", конечно, желательно после того, как все это сделано.

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

Компания работает в условиях жесточайшего цейтнота, соответственно проектировать и внедрять управление волей-неволей приходится в ходе реализации проекта. Так что же, в этом случае первично?

Что касается «большой компании», то в моем понимании Борис Федотов расписал не людей, участвующих в проекте, а роли. Соответственно, часть ролей может совмещаться и их будет выполнять один человек. Роль, также, может быть закреплена более чем за одним человеком. При этом образуется группа менеджеров, разделяющая одну роль. И, следовательно, эта группа должна быть каким либо образом структурирована.

P.S.:
Что можно сказать по поводу "типичных проблем начинающей компании"? Это пример, взятый мной из жизни. С подобными примерами я сталкивался несколько раз лично, а уж слышал о них – несчетное число раз :-))

-

Почитайте Microsoft Solutions Framework - интересная концепция. Главное жизненная, Microsoft утверждает, что именно так разрабатывает программы.

Что, они решили вторгнуться на рынок CASE систем, да еще и со своей терминологией ?
Сначала написал это, а потом - посмотрел что такое MSF. Угадал :-(.
Причем бизнес-моделированию уделено минимум внимания, а совокупной стоимости владения - максимум. Это и есть классический современный путь развития российских предприятий. Думаю, что поэтому MSF у нас в стране вполне сможет прижиться. К сожалению. К счастью - только на время "взросления" российского бизнеса.
Microsft-то разрабатывает лишь операционные системы и различные "редакторы". Корпоративных же информационных систем они не разрабатывают. Так что они могут предложить разработчикам ИС ??? - Поразрабатывать редактора. И только !

Это Вы здорово подметили! По поводу "лишь операционные системы"!

А как Вы полагаете, много ли в мире создали софта (да и любых других искусственных систем), более сложного, чем операционные системы вообще и операционки от MS, в частности?

Откровенно говоря, я просто восхищаюсь способностью MS производить сложное и качественное ПО в разумные сроки. Может быть, конечно, я ошибаюсь, но сможете ли Вы привести примеры более качественного ПО, того же класса, что производит MS? Я, честно говоря, в затруднении.

Константин, добрый день :-).
1. Я речь вел вовсе не о том, что MS делает ПРОСТОЕ ПО (или медленно делает), а о том, что они НЕ В СОСТОЯНИИ (были до сих пор) сделать приличную CASE систему - основу любой НОРМАЛЬНОЙ автоматизации, а делают лишь примочки, заплатки, вешая нам лапшу на уши про какую-то "идеальную офисную совместимость", в лучшем случае про "системы документооборота на основе Exchange".
Интересно, зачем тогда нужны фирмы разрабатывающие системы документооборота, в том числе "на основе Exchange" ? И чем они занимаются ? Да тем, что превращают недоделанный, недоведенный до конечного пользователя продукт - в рыночный, закрывая своими телами и нашими деньгами эти недоделки, жуки и др. дыры.
Когда говорят о качестве продуктов MS, я всегда вспоминаю одну гордую социалистическую поговорку:
"Нашу работу знают - плачут, но берут !"
Я говорил только об этом.
Если же Вы хотите поговорить и о другом, то немножко можно :-):
2. А что Вы считаете, что у ОС MS качество выше, чем у UNIX/Linux..., или чем у Novell ? Для меня качество серверной операционной системы - это, в первую очередь, ее устойчивость и надежность транзакционных систем, а только потом - функциональные возможности.
3. О СУБД: Или может быть Вы считаете, что MS SQL Server лучше, чем Oracle ?
4. О "разумных сроках": - это чисто маркетинговый ход - клонировать операционки с огромными хвостами из сервис-паков и патчей - это борьба за наши бабки, а не за качество ОС, т.к. никакой уважающий себя специалист не будет каждый год апгрейдить серверную ОС и СУБД, поскольку это "чревато" и дорого !
Именно на этих маркетинговых фокусах, вместе с ценовой политикой MS и вылезла туда, где она сейчас находится, а специалисты спят и видят, когда же Linux подрастет настолько (имеются в виду приложения, т.к. сама эта ОС давно переросла MS), чтобы смести MS с наших серверов.

Андрей!

Не могу промолчать в связи с Вашей последней репликой в форуме «Менеджмент в аутсорсинге». Вы наступили на мой больной мозоль – предвзятое отношение к лидерам рынка. Это отношение почему-то особенно процветает в нашей стране, где 95% пользователей считают допустимым воровство программного обеспечения. Мнение западных коллег, которые предпочитают покупать это ПО, как правило, резко отличается.

Мое личное мнение, сложившееся на основе, как минимум 15-ти летнего опыта использования продукции разных производителей: IBM, Microsoft, Oracle, Novell, Software AG, Borland и других, приводит меня к выводам, существенно отличающимся от предложенного Вами видения, поэтому я считаю необходимым изложить его в этом форуме, хотя, возможно, это тема отдельной дискуссии.

Итак.

1.

Насчет «… приличной CASE системы - основе любой НОРМАЛЬНОЙ автоматизации»

Не могу согласиться с этим тезисом.
Основа автоматизации – бизнес автоматизируемой компании. Способ – автоматизации – выбранная методология, которая может быть реализована и при помощи CASE и без них. Необходимое, но не достаточное условие автоматизации – грамотная команда автоматизаторов (как технарей, так и менеджеров) и более-менее упорядоченное управление компанией. Достаточным условием, по видимому, является все это вместе взятое плюс наличие ресурсов и четкого осознания целей этого процесса и границ возможностей технологий у высшего менеджмента (причем не только у генерального, но и у всей верхушки руководства). В этом случае, масштабное внедрение ИТ в компании имеет шансы на успех.
Что же касается «НОРМАЛЬНОЙ» CASE, то этим словом называют все что угодно, - ERWin, например. Это, конечно, вопрос терминологии, и я полагаю, что Вы имели ввиду те CASE, которые поддерживают полный технологический цикл разработки. Так вот, я что-то не припомню, когда Microsoft заявляла, что среди их продуктов есть такие CASE системы. Microsoft делает инфраструктуру и средства разработки и каким боком они относятся к CASE мне не понятно.

Насчет “ какой-то "идеальной офисной совместимости…" и «… в лучшем случае … "системы документооборота на основе Exchange".

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

К вопросу “ …зачем тогда нужны фирмы разрабатывающие системы документооборота»?

Да затем, что ни одна, даже самая-самая большая компания НИКОГДА не сможет охватить весь рынок. К тому же, как я уже говорил, Microsoft ориентируется на поставку инфраструктуры, а не конкретных решений. Они никогда не брались за разработку продуктов, рынок которых не измерялся миллионами экземпляров, а «…недоделанный, недоведенный до конечного пользователя продукт» и не может быть доведенным до конечного пользователя, если имеется в виду Exchange - продукт серверного класса. Можно ли, например, говорить о том, что ORACLE, CICS, Group Wise и масса других продуктов столь любимых Вами производителей - Oracle, IBM и Novell доведены до конечного пользователя?

2.
«А что Вы считаете, что у ОС MS качество выше, чем у UNIX/Linux..., или чем у Novell ? Для меня качество серверной операционной системы - это, в первую очередь, ее устойчивость и надежность транзакционных систем, а только потом - функциональные возможности».

Пример очень надежной и устойчивой программы:

#include "stdafx.h"
int main(int argc, char* argv[])
{
printf("Hello World!\n");
return 0;
}

Так важны или нет функциональные возможности? Если система в принципе не способна выполнять требуемые функции, разве важна ее устойчивость?

Что касается сравнений… да, я действительно полагаю, что NT не менее надежна, чем UNIX (Solaris или HP-UX) или NetWare. И уж точно более надежна, чем Linux. Результаты эти основаны на личном опыте и для меня сомнению не подлежат. Что же касается функционала – ни одна из перечисленных систем и рядом не стояла с NT, а уж тем более с Win 2000.

3.
«О СУБД: Или может быть Вы считаете, что MS SQL Server лучше, чем Oracle» ?

Привожу результаты независимого тестирования:

Ранг Система Производительность СУБД
1 IBM/eServer xSeries 370 688,220 Microsoft SQL Server 2000
2 ProLiant 8500-700-192P 505,302 Microsoft SQL Server 2000
3 Netfinity 8500R c/s 440,879 IBM DB2 UDB 7.1
4 IBM eServer xSeries 370 363,129 Microsoft SQL Server 2000
5 ProLiant 8500-X700-96P 262,243 Microsoft SQL Server 2000
6 ProLiant 8500-X550-96P 229,913 Microsoft SQL Server 2000
7 PRIMEPOWER 2000 222,772 SymfoWARE Server Enterp. Ed. VLM 3.0
8 IBM eServer pSeries 680 220,807 Oracle Oracle 8i Enterprise Edition v. 8.1.7

Результаты взяты с [ссылка] комментарии излишни.

В заключение.

«Борьбу за наши бабки» ведут все рыночные компании, просто одни ее выигрывают, а другие, соответственно, проигрывают. Вот эти другие и создают мифы о дьявольском везении первых и абсолютной не конкурентоспособности их продукции. А миллионы и миллионы клиентов голосуют своими кошельками.
Microsoft - гениальная компания и в технологическом и в маркетинговом и в управленческом плане. По моему, спорить с этим абсурдно.

С уважением,
Константин Глазин

Добрый день, Константин !
1. Приношу свои искренние извинения за то, что наступил на Ваш "больной мозоль". Если б знал заранее - не стал бы :-)).
2. Очень хорошо, что это лишь Ваш "больной мозоль", а не мой, поэтому, надеюсь, что, хотя бы теоретически, я смогу быть более объективным :-). Тем более, что для меня последние годы истина стала дороже побед :-).
3. Согласен с тем, что для маленьких предприятий CASE система не обязательна. Скажу больше - иногда и вредна :-).
4. Фраза с сайта MS: "Итак, Microsoft Solutions Framework (MSF) является комплектом моделей, концепций и руководств по созданию и внедрению распределенных информационных систем уровня предприятия."
Что же это, как не жалкое подобие CASE системы ? Знаете, на некоторых автомобилях ОКА пишут: "Когда я вырасту - стану джипом". Здесь примерно то же самое - ОКА.
Т.е. налицо попытка создания "средства разработки" ИС как бы снизу (или со средины), не обращая внимания (пока, естественно, т.к. без этого не обойтись) на отсутствие инструментария по формированию функциональной модели бизнеса, с чего, собственно и должно всегда начинаться проектирование КИС, будь эта модель в голове ген. директора, на бумажках или в CASE-средстве.
Цель всей этой возни - хоть как то помочь пользователям своих продуктов разгрести все те завалы в ИС, которые получились во многом благодаря бессистемному подходу MS к проектированию чего либо с помощью их продуктов.
Естественно - это исключительно мое субъективное мнение.
5. По поводу качества операционных систем. соглашусь с Вами, что устойчивость и надежность без функциональности - не нужны. Вопрос в приоритетах.
Мои приоритеты (для ОС и СУБД):
1. Надежность/ устойчивость/ достоверность данных.
2. Функциональность.
3. Цена
4. Производительность.
Глубже не рассматриваю, чтобы не расширять дискуссию.
Это, кстати, не истина в последней инстанции :-)).
6. В заключение: Искренне не сомневаюсь в талантливости Б. Гейтса, лидерстве MS на финансовом рынке и в том, что MS это - "гениальная компания ", но мне, да и многим другим специалистам это совершенно до лампочки. Т.к. нас интересует... см. п. 5 :-). А все остальное это - эмоции.
PS: Обязанность старшего по возрасту диктует мне предложить именно Вам высказать последнее (по времени) слово в этой маленькой дискуссии, т.к. лично меня она не очень сильно интересует :-))).
А вообще, неплохо было бы послушать и других специалистов.
Спасибо.

Да, совсем забыл сказать:
К чести Microsoft надо признать, что за последние несколько лет качество их продукции несколько улучшилось :-).

К сожалению таблица с рейтингами исказилась, но на [ссылка] можно все рассмотреть.

Не знаю как в России, но в штатах у MS весьма грамотное подразделение MS Consulting. Там полно народу из big 5. Году в 1998 мне довелось общаться с ними. Впечатлениея самые благоприятные.

А попытка влезть на рынок консалтинга - еще один шаг к диверсификации бизнеса.

Далее про стоимость владения. То что сообщает MS про TCO своих продуктов не совсем соответствует действительности. Просто информация благодаря прессе, до широкой публики доходит с искажениями.

А TCO - не основной, но тем не менее важный компонент оценки бизнеса.

MSF - ход конем. Прощупывание реакции клиентов, конкурентов и пр. Если кто помнит Multiplan, тот поймет. :)

-

Не думаю. Одно дело предлагать, другое дело самому работать. :)
Хотя сейчас идут глухие разговоры о том, что MS собирается купить кого-то из большой шестерки. Чтобы велосипед не придумывать.

-

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

Вопросы терминологии - это вопросы взаимопонимания людей. Это язык, на котором они говорят. Недооценивать их важность, по-моему - ошибочно.
Обратите внимание, что многие научные работы содержат в себе глоссарии определения терминов, которыми авторы пользуются в данной статье.
Здесь на сайте, конечно, есть увлечение терминологическими изысками, в основном, правда "импортными".
Интересно, это что - от неумения перевести на русский язык ? А переводить-то все равно придется, т.к. вся отчетность в стране идет на русском языке :-). Или пошиковать своим "языком" ?
По-моему здесь очень немного людей, кто принципиально не применяет терминов на англ. языке, что, лично мне, например, не мешает ни меня понять, ни мне - собеседника.
Так что я - принципиально за сохранение русскоязычной терминологии, как бы ни было кому-то лень (или "слабо") переводить эти термины на государственный язык страны пребывания.
И последне: понятие "функция" является базовым для подавляющего большинства как технических, так и многих других систем.

Граждане, давайте придерживаться английской терминологии. А то получится вроде:

Дивиденды=Доходность на вложения=Возврат инвестиций=Доходность инвестиций=Return on investment (ROI) ;)

-

Приветствую. :))) Рад видеть. :)))) К сожалению времени в обрез.

Ну... У нас финансисты вовсю матерят совковую бухгалтерию. Думаю, как начали вымирать "красные" директора, так и отомрут "красные" бухгалтера. Не в плохом смысле.

Финансовая культура на Западе всегда была высока. Выше, чем у нас.

А с терминами действительно хаос. Надо некий словарь вводить, чтобы путаницы не было.

-

Всем желающим могу выслать материалы этой конференции в формате MS Word или RTF.

Материалы актуальны на 19.05.2001

Константин,
Буду весьма признателен, если Вы вышлете мне материалы конференции на lapshin@bgs.ru
С уважением
Виктор Лапшин

Константин,
буду признателен если вышлете мне тоже материалы по ttc@mail.wplus.net.
С удовольствием слежу за дискуссией с прошлого еще форума, но время не позволило принять активного участия в обсуждении по теме. Мне кажется, что при обсуждении рисков стоит обратить внимание и на "отрицательные" примеры ошибок при реализации проектов. Например, возникновение конфликтов "предприниматель-менеджер-технарь" как в случае выбора Project manager, так и при выполнении двух или трех из этих функций одним и тем же человеком в рамках небольшого проекта или небольшой фирмы.

С уважением,
Андрей Праницкий

И мне тоже , пожалуйста, вышлите. Заранее спасибо, Константин, что Вы на одном дыхании сделали документы.barbara@tomstudio.ru

Константин, добрый вечер, приятно познакомиться.
1. Прошу выслать мне материалы (alan@eltorg.ru).
2. Скажите пожалуйста: какова цель этой рассылки ?
Спасибо.

Рассылка не целевая, просто я собрал все в Word-е для того, чтобы самому было удобно работать с материалом (мне понравилась Ваша идея со статьей, ну я и решил сделать краткий реферат по форуму, чтобы коллегам было удобно работать с материалом. Если, конечно, они поддержат идею).

Вышлите мне на im@econobest.com

Достаточно интересная у Вас получилась беседа. Я следил за ней еще в прошлом форуме, где "троица" профессионалов с огромным темпом и напористостью обсуждали обозначенные проблемы. В результате, лично я, к примеру, не смог, не успел даже все прочитать, не говоря уж о том, чтобы слово вставить :-), а тем более проанализировать и осмыслить :-(. Причина - как известные проблемы читабельности сайта, так и банальный недостаток времени. А разговор у Вас получился, в основном, конструктивный, и, главное, полезный не только для оффшорцев и аутсорцев :-), но и для других менеджеров. В связи с эти у меня родилась мысль. Попытаюсь ее сформулировать в виде предложения к Вашей "троице", а может быть и не только к "троице " (это там Вам видней).
Я предлагаю Вам проанализировать Ваши диалоги, вычленить квинтэссенцию темы менеджмента в аутсорсинге и подготовить совместную статью для ее публикации (к примеру, здесь на сайте). Можно - в чьем-то личном форуме, как это делаю я, а можно в публичном, а может быть, договорившись с рук. сайта - отдельной статьей. Лично я Вам скажу большое спасибо за такую "работу", впрочем, уверен, что далеко не только я. Ну как, не слабо ? :-))

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

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

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

Потом написанную статью опубликуем в форуме, а если договоримся с Ward Howell, то опубликуем отдельной статьей.

Кто "за", голосуйте!

P.S.:
Может быть, у меня получиться обработать материалы форума прямо сегодня.

Имхо, надо просто произвести компиляцию материала. Плюс каждый из участников форума дает свою оценку в своеобразных врезках. Плюс резюме.

Это уже интереснее, так называемая конференция по материалу с конечной выдачей результата в конце в виде обзора, который и еще сопровождается форумом :-)))
Короче говоря, непрерывный поток материалов,который плавно перетечет в книгу :-))
Кстати, очень много слов, высказанной на этой конференции косвенно отражаются в книге Эдварда Ферна "Управление проектами Time-to Profit"/ Очень интересная и неожиданная книга :-)

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

Присоединяйтесь, будем вместе "плавно перетекать в книгу" :-)))

Кстати, может быть дадите наводку - книга где продается?

Угу. :)))

Полностью согласна с Андреем, по поводу создания обзора. Но ,дело это трудное, по ряду нескольких причин, одна из которых заключается в том, что говорить по ходу беседы легче, чем писать сразу большой обзор, обобщая большие речевые данные :-)
Я тоже жалею, что не принимала участия в беседе :-(, училась интенсивно на корпоративном тренинге.

Варвара, доброе утро.
К сожалению, не могу согласиться с этой мыслью :-).
1. Когда материал уже наговорен и его "сборщик" и будущий автор владеет вопросом, то задача решается за несколько часов.
2. Речь я вел не об обзоре различных методологий управления, а о синтезе некоего "оптимального" по мнению авторов способа управления подобными проектами.

Мы тут здорово и правильно рассуждаем, но господа, насколько это все далеко от реальности!

Давайте попробуем немного к ней (реальности) приблизиться. Давайте рассмотрим такую ситуацию:

Дано:

Российская компания, не стартап, но молодая. Создана под реализацию конкретного проекта. Проект реализовывала три года. Довольно успешно – заказчик, в основном, удовлетворен и понемногу заказывает расширения и изменения в проекте.

Основные черты компании:

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

Проблема:

После перехода проекта в стадию стабилизации, основные силы компании оказались свободными. Руководство компании приняло решение развиваться в направлении реализации заказных проектов. Оценив рынок, они пришли к выводу, что выгоднее будет использовать свои связи с коллегами в Европе для поисков западных заказов и ориентировать разработчиков на производство софта на экспорт. Через некоторое время, генеральный получил предложение от немецкой компании и вылетел на переговоры. Вернулся он с заключенным контрактом стоимостью $450000.
После заключения контракта, генеральный решил, что таким проектом должен управлять профессиональный менеджер и нанял, … ну допустим, Вас.

Вопрос:

Что Вы будете делать, чтобы в такой компании организовать проект?

P.S.:
Этот пример не надуман – это описание ситуации, возникшей в действительности. Причем, такая компания - типичный пример новой компании по разработке софта, возникшей на нашем рынке.

Сегодня в Нетоскопе [ссылка]
Вот вам и менеджмент.....

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

Угу. При всем этом задача проджекта - оперативное управление. Включающее управление инф. потоками, контроль исполнения, оперативное и отчасти тактическое планирование.

Сорри, взаимодействие с заказчиком - эккаунт менеджер.

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

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

Можно пойти другим путём, создать государство в государстве. Полностью отделиться от старой структуры. То есть реорганизовать разработчиков, по возможности назначить тим-лидеров из их числа, это сгладит конфликт меду менеджерами и разработчиками, пострить структуру, о которой тут уже говорилось, причем желательно посадить их вместе в одной комнате, так чтобы развитие проекта было бы абсолютно прозрачно для всех участников, тогда не появятся обвинения в нахлебничестве. Да и поддерживать порядок в замкнутом пространстве легче. По мере расширения проекта привлекать либо старый состав, который уже не сможет сопротивляться новым порядкам, либо заменять новыми людьми. Во всяком случае первая задача - отсечь всё, что может мешать работать, какается ли это бухгалтерии, менеджмента или режима работы. В конце концов, найти какое-нибудь занятие людям, кототороые, по вашему мнению, могут тормозить процесс. Пока они поймут, что произошло, будет уже поздно:)

Какие есть мнения по поводу построения оптимальной модели взаимодействия с клиентом?
Я вижу несколько вариантов:
1) Project Manager занимается всем - продажами, управлением проекта, рабочим общением с клиентом т.е. совмещает в себе все функции
2) Sales, Project Manager. Есть специалист по продажам, который занимается исключительно поиском клиента. При его нахождении и достижении некоторых предварительных договоренностей он передает клиента Prоject Manager для дальнейшей работы.
3) Введение системы эккаунт менеджера. Все общение с клиентом ведется через специального специалиста, который только тем и занимается, что общается с клиентом, после того как он найден Sales.

А мне кажется близкой к оптимальной такая можель команды:

Менеджмент проекта:

1) Менеджер продукта.
Обеспечивает коммуникации между заказчиком и проектной группой, управляет ожиданиями заказчика, разрабатывает и поддерживает бизнес-контекст проекта. Его задача — определить и обеспечить удовлетворение заказчика.

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

Реализация:

1) Разработчик
2) Тестер
3) Инструктор
4) Внедренец

Что скажете?

куда только сэйлза приткнуть в этой структуре?:) А в остальном согласна.

Во-первых, безусловное отсечение команды разработчиков от клиента.
Во-вторых, получается некая смесь пирамидальной и матричной структуры. Наиболее же эффективны так называемые плоские структуры.

А сейлза сюда притыкать и не нужно!

Сейлз, а точнее маркетинг, свою работу уже сделал. Теперь идет проект, и контакт с меркетерами минимален. Он есть тоько у менеджера продукта. Да и то, не регулярный, консультативный.

Маркетинг в это время уже занят окучиванием следующего клиента, связывания его со следующим менеджером продукта и т.д.

Какие есть мнения по поводу построения оптимальной модели взаимодействия с клиентом?
Я вижу несколько вариантов:
1) Project Manager занимается всем - продажами, управлением проекта, рабочим общением с клиентом т.е. совмещает в себе все функции
2) Sales, Project Manager. Есть специалист по продажам, который занимается исключительно поиском клиента. При его нахождении и достижении некоторых предварительных договоренностей он передает клиента Prоject Manager для дальнейшей работы.
3) Введение системы эккаунт менеджера. Все общение с клиентом ведется через специального специалиста, который только тем и занимается, что общается с клиентом, после того как он найден Sales.

На мой взгляд вариант следует выбирать в зависимости от размера вашей компании, наличия или отсутствия стандартных управленческих процедур в ней и сложности проекта.
Я считаю, что проекты стоимостью от 500К внедрение которых занимает сроки в среднем 6 месяцев удобно вести по схеме Sales -> Project manager + Account manager. PM и AM занимаются разными проблемами. Причем в общении с заказчиком наличие двух людей бывает иногда очень полезным. Здесь можно играть в разные "игры".

Не всегда. Заказчик тоже может ввести парную комбинацию. Тогда информационные потоки будут конфликтовать.
Наилучший вариант -1 на 1.

Я учавствовала в проекте стоитмостью 300К и в общей сложности он длился 1,5 года. Я не думаю, что проект от 500К занимает 6 месяцев. Во всяком случае у меня таких примеров перед глазами не было. Чаще приходилось встречаться со схемой сейлз - проджект-менеджер - тимлидер. Внутри проекта всегда есть деление на команды, поэтому тимлидеру нередко приходится общаться с представителем заказчика по конкретной части проекта.

Средняя скорость освоения проекта разработки - 20-80 К в месяц. У нас. НЕ берем в расчет исключения. Там - может доходить и до 150 К в месяц.

Возможно пример был недостаточно хорош - речь идет не разработке с нуля за 6 месяцев, а о кастомизации некоего готового ядра.

По-поводу структуры, то в большой компании (>200-250 человек связанных с процессом разработки) она как правило такова:
- project sponsor (top manager)
- account manager
- project manager
- project manager of subproject(s)
- business & requirements analyst(s)
- program manager(s)
- team lead(s)
- developer(s)
- tester(s)
- documentator(s)

извиняюсь за английские названия :)

Если компания реализует несколько проектов, то как правило структура матричная. Т.е. ресурсы PM’у выделяются исключительно на время реализации проекта.

Извиняюсь, к сожалению при submite пропала табуляция, так что потерялась структура иерархии :(((

Это ничего, всё равно понятно, тем более, что присутствующие знают, о чём речь:)

Первый вариант отпадает сразу. Нельзя объять необъятное, потом редко кто совмещает талант продавца и знания и умения руководителя команды. Такие люди встречаются крайне редко.
Второй вариант пожалуй оптимален. Общение с клиентом на этапе разработки требует детального знания технических условий, сейлз просто физически не может знать всех подробностей проекта. Более того, когда начинается реальная работа, со стороны клиента выступает не покупатель конечного продукта, а технический специалист. Тут переговоры идут на уровне технарь-технарь. Клиента интересует конечный результат, ему не интересны технические подробности и проблемы, с ними связанные. Эти вопросы решаются обычно с представителем заказчика, который хоть что-то понимает в этом деле.
Третий вариант. Слабо представляю. Ведь в этом случае эккаунт-менеджер должен детально знать проект, то есть очень хорошо быть знаком с программированием и отслеживать всё, что происходит в процессе работы. Плюс еще промежуточное звено в структуре сейлз-эккаунт-проджект менеджер. Несколько громоздко.

Воспользуюсь терминологией уже упомянутого мной как-то Эдварда Йордона.:) В прошлой дискуссии часто повторялся один и тот же вопрос, суть которого проста - что надо сделать, чтобы сделать успешный бизнес в программировании, а еще проще - как не превратить путь самурая в путь камикадзе. Всех вдохновляет успех Билла Гейтса (пример напрашивается сам собой), и всем бы хотелось достичь чего-то подобного. Вопрос только, как? Все разговоры об необходимости внедрения всяческих средств управления проектами и соответсвие ISO наталкивает на мысль, что успеха можно добиться, если соблюсти все формальности. Что-то вроде задачки из журнала "Красная Бурда" - "В какой последовательности надо нажимать клавиши печатной машинки, чтобы получить в результате роман "Война и мир"?". Казалось бы что проще, внедрим стандарты, пройдем все необходимые сертификации и золотой ключик у нас в кармане. На деле получается совсем не так здорово, потому что упускается одна существенная деталь - сама идея проекта. А идея - штука творческая, ISO тут не поможет.
К чему я всё это. Не слишком ли много внимания уделяется формальным процессам, в то время как совершенно забыто о самом главном - в основе успешного проекта стоит хорошая идея. Мы говорим о выходе на западный рынок, ни разу не упомянув, с чем собираемся выходить. Это ли не задача менеджмента ставить неординарные задачи и находить изящные способы их решения? Остался ли вообще хоть какой-то творческий потенциал или весь этот славный топ-менеджмент погряз в создании громоздких бюрократических структур, работающих сами на себя?

Вопрос: есть идеи? Любые. Был ли опыт в создании собственных систем управления в своей компании? Опыт в подборе команды? Как решались проблемы, связанные с человеческим фактором? Не секрет, что в этой области он играет важную роль, условия-то тяжелые, работа командная, часто еще и удаленная. Вобщем любые творческие решения, о которых вспоминают с гордостью.

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

А что есть талант бизнесмена как ни талант менеджера:) По моему скоромному мнению это одно и то же:)

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

А по моему, бизнесмен (предприниматель - entrepreneur) и менеджер (manager) - суть разные вещи.
Один воплощает идею в жизнь и создает бизнес, другой же этим бизнесом управляет (планирует, реорганизует, учитывает, продает и т.д.).

Конечно, эти две ипостаси могут воплатиться и в одном человеке (яркие примеры - Бил Гейтс или Джон Рокфеллер), но чаще всего это разные люди.

А кто управляет менеджерами в данном случае? Кто стоит во главе всего, тот самый топ-менеджер?:) Команду менеджеров-то он набирает. Если не нравится Билл Гейтс, то другой пример - Тед Тёрнер...

А менеджерами управляет СЕО - высший наемный менеджер в компании, а им уже никто не управляет. Он подотчетен акционерам (т.е. предпринимателям), но они им не управляют.

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

Это взаимопроникающие понятия - высший управленец и предприниматель.

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

А для препринимателя - способность увидеть перспективную инновацию, организовать ее финансирование, создать нужную организацию и вывести инновыйию на рынок. А затем, либо самому превратиться в управленца, либо нанять наемного.

Не управляют, но уволить могут:)

С интересом поучаствую в дискуссии.

Я сейчас создаю с партнером (и другом, конечно) компанию по заказному программированию.

Start-up стандартный:
- партнеры в Англии (дизайн-студия), у которых куча заказов, и они очень заинтересованы в дешевой рабочей силе здесь.
- англичане вкладывают средства в офис

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

Про ISO тоже хочу сказать, что он не нужен средней компании-разработчику, а уж тем более начинающей. Можно качественно организовать бизнес-процессы и необязательно сертифицироваться. Заказчик и сам все увидит, без бумажек. Об ISO можно говорить уже на высоком уровне, при участии в серьезных проектах, от 500K и выше.

И какой все-таки неудобный форум...

Можно все в WORDе и на бумажках конечно делать, но Миллениум как-никак.

Первое, что приходит на ум - Microsoft Project 2000. Насколько эффективен/удобен/полезен?

Какие есть аналоги?

Интересен реальный опыт использования. Продукты за 100K можно не рекомендовать :-)

Можно все в WORDе и на бумажках конечно делать, но Миллениум как-никак.

Первое, что приходит на ум - Microsoft Project 2000. Насколько эффективен/удобен/полезен?

Какие есть аналоги?

Интересен реальный опыт использования. Продукты за 100K можно не рекомендовать :-)

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

Был опыт с MS Project, к сожалению, неудачный из-за нелепого его использования. Точнее, проджект менеджер требовал КАЖДОЕ действие заносить как задание. В результате, если требовалось узнать имя файла или фолдера, надо было писать задачу сотруднику- ответить на вопрос:)) Такое вот тоже бывает.
В основном же пользовались своим интранетом, программные средства использовались разные от Lotus Domino до ASP, PHP.

Любое правило и любую методику можно довести до абсурда. Слепое воплощение методик в жизнь, предпринятое в частности, вашим проджект менеждером ведет не к четкой организации проекта, а к управлению проектом в интересах самого процесса управления, а не в интересах проекта.

Дело не в методике даже, она сама может быть очень хорошей, а в её использовании. В любой системе роковую роль играет человеческий фактор, не учитывать его по крайней мере опасно.

Боюсь, что не учитывать его будет смертельно.

На самом деле вот простые принципы, которые позволят организовать проект среднего масштаба (если выражать в объеме кода, то 100-200 тыс. строк).

Принципы организации проекта:
1) управление рисками и их планирование;
2) выпуск промежуточных версий;
3) планирование деятельности;
4) четко обозначенные контрольные точки проекта;
5) проектные группы небольшой численности.

Принципы организации проектной группы:

1) взаимозависимые и взаимосвязанные роли в малой группе;
2) определение роли, особой миссии и зоны ответственности для каждого члена проектной группы;
3) распределенные управление проектом и ответственность;
4) каждый сфокусирован на успехе проекта и настроен на работу в течение всего цикла проекта;
5) коммуникации между членами проектной группы являются ключевым фактором успеха;
6) пользователи и обучающий персонал включены в проектную группу;
7) параллельная работа всех участников группы над проектом.

Я бы добавила в первым пунктом в Принципы организации проекта: Постановка задачи.

Отсутствие постановки задачи или ее нечеткость - один из рисков проекта по разработке чего угодно (софта в том числе).

Так что, управляйте рисками!

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

Я как раз тот менеджер из "другой" отрасли (кому интересно - см. мой профиль), к-рому предложили поработать менеджером проекта в отрасли, активно обсуждаемой в данном форуме. В связи с чем читаю все сообщения с большим интересом.
М.б. я покамест не силен в оффшорном программировании, но в управлении проектами (на производственных предприятиях + на весьма сложных рынках) кой-чего соображаю. Мне не вполне понятна сентенция насчет того, что менеджеры "особенно пришедшие из других областей категорически отказываются....." Что за ерунда? Есть менеджеры хорошие и не очень хорошие. Это не зависит от отрасли, из которой они пришли.
Кстати, многие топики в этом форуме изрядно забавляют именно своей "детскостью", такое впечатление, что основы менеджмента для участников (постановка задач, планирование и проч.) - нечто новое, на грани откровения.
Уверяю, что во многих отраслях нашего нар. хозяйства азбучные истины менеджмента давно освоены - дисциплина производства того требует. Так что имхо лучше говорить о квалификации и опыте отдельных менеджеров.
Всем удач.

Однажды, в далеком 1975-м году, два молодых американских парня в гараже отца одного из них создали персональный компьютер. Парней звали Стив Джобс и Стив Возняк. Через некоторое время, они создали фирму Apple, выпускающую эти самые компьютеры. Еще через некоторое время эта фирма заняла практически весь рынок, а ребята омиллиардились.

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

Apple год за годом заканчивала с убытками. Так продолжалось долго, ровно до тех пор, пока те же самые акционеры не пригласили нового СЕО, которым оказался …. Стив Джобс! Ну а теперь компания опять вышла на прибыльность.

Вот ведь история какая!

Ну и что? А где компания NEXT, созданная тем же Джобсом?

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

К сожалению, тем же Джобсом была выбрана неверная рыночная стратегия - разработка уникальной компьютерной архитектуры. Но! Решения, созданные в NEXT, пару лет назад взяла на вооружение "новая" Apple - результат налицо. Кстати, трудно сказать (мне лично это не известно), была ли NEXT успешным бизнесом. То что она не повторила успеха Apple, вовсе не означает того, что она не была успешной!

Первая на рынке - это очень сомнительное конкурентное преимущество. Большинство компаний первопроходцев заканчивают свой бизнес печально.

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

С первым не согласен. "Первая на рынке" - конкурентное преимущество по всем учебникам бизнеса :) Другой вопрос, что после этапа генерации идеи (первая на рынке), наступает время этапа - развития бизнеса (менеджмент). И тут уже не все могут...

Второе - согласен. Закрытость архитектуры не дала ей уйти в массы, как в случае PC.

Первая не в историческом смысле. Первая по объему рынка.

А закрытость была абсолютно оправдана в тот период! IBM тоже сделала бы закрытую архитектуру, если сумела бы!

А вот Скалли и должен был эту модель менять, когда все начали клонировать IBM и Apple стала терять рынок. А он этого не сделал!

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

Правда, конечно!

Но факт остается фактом - один человек (Возняк здесь не в счет - он никогда не был хорошим менеджером) создал клмпанию и выввел ее в мировые лидеры, а потом была череда руководителей (был ведь не только Скалли) и компания чать не загнулась. Человек вернулся - и снова подъем. Это факты, а факты, как известно, вещь упрямая!

У каждого из нас бываю удачи и неудачи. Вопрос лишь в том, чего больше. Я думаю, Джобсу достаточно и Apple, чтобы стать авторитетом в своей области. Дело не в том, что НЕ ПОЛУЧИЛОСЬ, а в том, что ПОЛУЧИЛОСЬ И РАБОТАЕТ.

Ни однна бизнес-школа не гарантирует, что за уплаченные деньги сделает человека талантливым. И что-то цитаты из фильма "Золушка" в голову приходят, про связи, которые не сделают "сердце добрым и ляляля...."
У Йордона был замечательный пример из истории создания Apple и о Джобсе в частности:))

Кстати, к Скалли не подходит тезис "ни однна бизнес-школа не гарантирует, что ... сделает человека талантливым" - он явно талантливый менеджер. Но с Apple справиться не сумел, видимо нужно было продолжать разливать Pepsi :-))

А пример Скалли этого положения и не опровергает:) Но, видимо, ему надо было стать Джобсом. чтобы руководить Apple.
Думаю, у Джобса тоже с Пепси ничего не получилось бы, получи он такое предложение.

Мне кажется, разница в том, что для руководства Пепси достаточно знания отрасли и бизнес-образования, для Apple кроме этого нужен еще и творческий подход.

А вот здесь наши мнения расходятся. По мне, творческий подход нужен везде!

Это правда лишь необходимое, но не достаточное условие повышенной успешности менеджера.

Валерий, абсолютно согласен, что "Есть менеджеры хорошие и не очень хорошие. Это не зависит от отрасли, из которой они пришли."

Что же касается "детскости", то несколько некорректное, на мой взгляд, суждение. Я был участником не одного проекта, некоторые из которых возглавлял. Среди проектов были и весьма сложные и длились годами (если Вам это о чем ни будь скажет - более 1000 таблиц в базе данных, более 2000 классов в программном обеспечении и более 40 клиентских приложений). Как ни странно, все (без исключений) проекты были успешными. При всем при этом, информацию о менеджменте я получал исключительно из литературы и опыта, не имея специального образования (можете посмотреть мой профиль).

Что же касается обсуждаемых в форуме вопросов, то мы обсуждали не теорию управления, а те проблемы, с которыми нам приходится сталкиваться в повседневной практике.

Так что суждение Ваше, в некоторой степени, обидно!

А то, «…что во многих отраслях нашего нар. хозяйства азбучные истины менеджмента давно освоены - дисциплина производства того требует» – это очевидно, так стоит ли об этом говорить? Нар. Хозяйство, худо-бедно существует, значит и менеджмент тоже.

С уважением,
Константин Глазин.

Вот и удивительно, что очевидные вещи не очевидны для менеджеров, пришедших со стороны. Это личный опыт и неоднократный. Для меня загадка, как можно управлять проектом, не зная специфики отрасли, не имея практического опыта создания хотя бы сайта, а что уж говорить о сложном программном продукте. Как можно распределять обязанности и ставить задачи, не имея представления о прораммировании и о технологиях в частности? Может быть у вас есть конкретный опыт? Как вы формируете команду на проект? Кто общается с заказчиком в таком случае? Ведь вряд ли вы мсможете объяснить клиенту, почему продукт не будет работать под WIN3.1, например, или почему вы используете PHP, а не ASP.
Про отказы писать спецификации - не единичный случай, и причина проста: сторонний менеджер просто не знает, как её писать, эту самую спецификацию и что в ней должно быть. А если учесть, что в оффшоре таких спецификаций как минимум 2 - одна для клиента: общее описание проекта, написанное максимально понятным языком без технических подробностей, и вторая - для разработчиков и специалистов - техническое описание, то это его окончательно ставит в тупик. В результате либо конфликты с разработчиками либо бардак.
Азбучные истины - это общие понятия. Здесь мы как раз обсуждали КОНКРЕТНЫЕ вещи, имеющие отношение именно к аутсорсингу. План работы отдела продаж продовольственной компании ничего общего, кроме слова "план", с планом написания ПО не имеет.

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

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

При случае было бы интересно пообщаться на тему в реале, расставить точки над Ё насчет переплетения вопросов менеджмента вообще, менеджмента в частности, необходимого уровня грамотности и многого другого.
Знаю только, что хороший ПМ джолжен быть по природе своей, так сказать, project-minded. Далеко не каждый программист (инженер) может в итоге стать менеджером... Для начала мозги д.б. обращены совершенно определенным образом.
А технический ликбез в объеме потребного минимума - это не проблема.
На вопрос почему вы используете PHP, а не ASP даже если я не знаю ответа прямо сейчас, завтра буду знать (если у меня хоть немного политехническое/"технократическое" мышление, в то же время свободное от опр. отраслевых стереотипов. А вот умение выстроить и реализовать проект - это нечто, что за две недели не "возьмешь", не правда ли?

Это конечно правда, "сделать" программиста - неделя, максимум две. "Сделать" менеджера? Это посложнее будет.

Валерий! Я ГОДАМИ подбираю программистов!

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

Чуток отвлекусь. Моя деятельность в авиации началась с того, что я пришел проситься менеджером по маркетингу/сбыту на авиаремонтный завод. Коммерческий директор немедленно стал пытать, мол, знаю ли я вообще что такое авиаремонтное производство, мол, знаком ли я с устройством самолета и т.д. и т.д. Ему (КД) некуда было деваться, ему был нужен человек с английским, он меня взял. И что же? Все, что мне требовалось знать про устройство самолета и все тонокости производства (в части касающейся) я знал уже через месяц-два, "пропустив через себя" два отремонтированных самолета и вволю наобщавшись с заказчиками.

Это я к тому, что МП естественно должен разбираться в технической стороне проекта (сам улыбнулся пока по клаве стучал). Но не только. И не столько. Не обязан я как МП знать С++ или SQL на уровне программиста. Такое знание мне как МП не только не будет помогать, а наоборот, будет мешать, перегружая меня излишней информацией, да создавая внутри меня всякие опасения и комплексы. Если я сейчас невнятно выражаюсь, то можно в выходные встретиться и пообщаться наяву.

Увы:) Мы тут из разных городов:) Я например, из Петербурга, так что встретиться не получится. Константин, кажется из Харькова, если я не ошибаюсь.

Интересно, почему по умолчанию считается, что всё происходит в Москве?:))

-

Ну этого я не говорила, но ограничивать вселенную Садовым Кольцом или МКАД я бы не стала.

-

А лях его знает, честно говоря:)))
Ну что же, будем обходиться средствами интернета и старательно понимать друг друга:)

Ошибаетесь, я уж 11-й год в Москве тружусь!

Во всяком случае, и программистов и менеджеров надо "подбирать" и обучать годами. И то и другое во многом искусство, а не техника.
Так что предлагаю заняться делом, которое начал Костантин :-))))

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

Кстати, чтобы руководить этими специалистами нужно еще заработать у них авторитет, авторитет профессиональный, иначе у пришлого менеджера возникнет конфликт, примеры можете почитать на РИКНе.

А хороших менеджеров везде мало. Очень субъективное мнение - "не из всякого инженера выйдет хороший менеджер". Я бы сказала иначе - "не из всякого человека выйдет хороший менеджер". Научить быть лидером нельзя, буть это хоть сто раз МВА.
положение "я умею планировать, а что планировать - не имеет значения" тоже не верно. Можно ради интереса поставить задачку из реальной жизни:) А вы напишите план:) А мы его раскритикуем в пух и прах:) Хорошая проверка на прочность:)

Согласен!

А программистами я называю всех, кто задействован в реализации технической части проекта. Сюда входят и аналитики и программисты и проектировщики-архитекторы, специалисты по базам данных и инфраструктурам и т.д. и.т.п. Перечисление можно продолжать и продолжать.

Что же касается "я умею планировать, а что планировать - не имеет значения", прочитайте мою реплику "Интересная история" в этом же форуме - яркий пример, а главное - из жизни!

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

Ну, простите, это маразм отказываться от документации. Такие менеджеры нам не нужны!

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

Вообще говоря управление рисками это стандартная функция PM’а. Так же как risk report такой же стандартный документ как и Project status report. Можно почитать методику PMI или курсы IBM на эту тему. И то что кто-то не считает это своим делом, просто говорит либо о лени, либо о квалификации.

Кстати, не посоветуете, где в сети можно найти материал по этой теме, наиболее интересный на ваш взгляд?

Есть методика RUP (Rational Unified Process) - описание можно найти на сайте [ссылка] (на вражеском языке) или на сайте Интерфейса (на русском, но не полностью). Эта методика описывает все, что связано с software process, в том числе и управление рисками.

Спасибо!

В первую очередь видимо [ссылка] Есть также методики Oracle и IBM. Не уверен, что это так легко найти в сети бесплатно (по крайней мере я не пытался). Но у меня есть сами документы. Если интересно пожалуйста пишите мне на fba@softhome.net или на boris.fedotov@montel.li.

Есть специализированный софт по управлению рисками, в том числе и рисками ИТ проектов. Но стоит он... Я знаю по крайней мере один продукт, в бета-тестировании которого принимал участие. Так вот стоил он в базовой комплектации - 64К.