Руководитель проектов 1с с чего начать

Обновлено: 04.07.2024

Собственно можно ли руководить группой программистов, не умея программировать?

Знаю, что был тренер по плаванию, не умеющий плавать. Готовил чемпионов :)

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

(0) не правильный вопрос. Правильный вопрос:

А должен ли руководитель группы разработки 1С знать 1С?

Должен ли руководитель что-то уметь? Конечно нет. Руководитель должен руководить. как можно руководить процессом не имея понятия, как это процесс в принципе "проводится" ?

(1) Я про руководителя группы разработки, а не про руководителя проекта!

С РП все понятно:
Вчера к нам пришел РП по УПП.
Первый его вопрос был - что такое УПП?
Я ответил - Что это такая типовая конфигурация 1С.
Второй вопрос был - И как его внедрять?
Я ответил - вначале заполнить справочники, потом вводить документы ;)
Третий вопрос был - Сколько тебе нужно времени, что бы все это сделать?

Лишь-бы руки были позагребущее и водить ими умел. Эта должность для пробивания и выбивания. Лучшие претенденты из бокса в руководители проектов приходят :) Зачем им что-то знать?

Собственно можно ли руководить группой программистов, не умея программировать? нет

Должен ли руководитель группы разработки 1С уметь программировать 1С? нет

Назначить подчиненным з/п отстатыщ и можно не париться (0) а можно ссылочку на этого феноменального тренера? :-)
по существу - конечно, он должен знать технологию программирования - иначе, как он сможет оценить объем работ? лапшу на уши враз повесят (8) на моей памяти был директор, звонит
- У нас сеть не работает. Сколько тебе надо минут, чтобы все починить? (17) для этого можно иметь техконсультанта, который лапшу с ушей снимать будет. (14) То есть как нет, когда я знаю примеры что да.
Причем много примеров, и весьма успешных.
Вообще не умея программировать. (0) Все зависит от того, насколько у него развита интуиция в качестве подобранных им кандидатов на программиста. В обратной зависимости от знаний подчиненных. Учитывая, что на Мисту за птицы залетают, однозначно (17) Кроме этого, ему не мешало бы знать внутреннюю структуру и ограничения платформы. (16) И что тебе это знание даст для управления?
Управлять программистами это значит держать их на коротком поводке. (20) тогда зачем он нужен? - пусть техконсультант всем и рулит :-) (26) а как он их будет держать? ему скажут - эта работа на 8 часов, а на деле - за полчаса можно сбацать (27) Раздавать всем звиздюлей. А то шибко умные попадаются. Вместо работы по проекту начинают изобретать Сверх Гениальные Программы. Руководитель сейчас как грязи. бестолочь одна.
Должен быть профи который сам все прошел и знает лучше своих подчиненных. только тогда он может уважуху заслужить, а иначе его нах слать будут. должен ли руководитель атомной электростанции знать как она работает и как организованно у нее все внутри и снаружи? Любой руководитель должен досконально знать работу своих подчиненных. Исключением являются только непосредственно бизнесмены. (31) все подряд - звиздюлей? или избирательно?
если второе - то как он отличит зерна от плевел? Тимлидер не должен уметь программировать?
А мальчики/девочки для подписания бумажек теперь все рукоблудители проектов? РП бывший пилот.
Управлял БОИНГОМ, вот руководство думает БОИНГОМ же сложнее управлять, чем УПП, значит справится!
Самое интересное буду выкладывать в этой ветке, пока не закроют её! (30) Отличить работает человек или в конру режется можно и без знания 1С. Халтурщики которые левые проекты делают, на себя работают тоже на раз вычисляются без знаний чем процедура от цикла отличается. (37) не надо грязи! руководство думает, что твой РП просто хороший парень, с которым приятно пить пиво и пилить бюджеты. (37) Если бы он раньше руководил овощной базой, т.е. людьми, а не железякой тогда было бы больше пользы для проекта. Хотя вроде практически все руководители в разработке успешных игр - бывшие программисты. +41 хотя не исключено, что у него есть так же талант руководства людьми и при назначении на должность РП это учитывалось (21) кхм.
руководить разработкой 1С можно не зная 1С.
руководить группой программистов не имея представлений о программировании неполучится, руководитель автоматически переводится в разряд постановщика задачи - прокладкой между конечным пользователем и программистом. "переводчик с кошачего"

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

Иначе такая фигня может получиться :)

Но в теории знать про все возможности. т.е. достаточно курсов 1с (8) пардон так руководитель разработки или руководитель проекта (46) вот, именно - постановщик
а то по Ахиллесовой схеме проги сами себе задачу ставят и сами выполняют, а РП их только попинывает для профилактики (отвлекая от работы) Он должен быть скорее квалифицированным пользователем и относительно неплохо разбираться в структуре данных Должен, ибо руководить процессом можно только понимая в нем, иначе, ИМХО результата не достичь. Есть правда одно "но": Если для такого руководителя в случае провала проекта всегда проканывает: "Это починенные м..аки, а я весь белый и пушистый". Тогда, правда, вообще чем хочешь можно руководить :))) (49) В (8) Это уже нанятый РП, в (0) Это поиск РГ, пытаюсь доказать руководству, что этот человек должен знать 1С! (0) Руководитель никому ничего не должен из своих подчиненных, это ему должны выдать результат уже готовый, за который платять бабло, а как и что крутиться - это не его дело. (5) Видимо АвтоВаз По этой же причине до сих пор в зачаточном состоянии) РУководителей полно) но непонятно чем они руководят) Я сейчас работаю с мужиком, который очень хорош в качестве постановщика задач - когда то давно он сам настраивал 1С 6.0, когда появилась семерка он для себя решил, что сложность программирования в семерке уже переросла его возможности программирования и разбираться с семеркой как программист уже не стал, то же относится и к восьмерке. Однако в качестве постановщика задач и придумывания новых возможностей для пользователя оно очень хорош. (38) в экран его монитора смотреть целый день будешь? о_О

Была одна бабушка, так всё время себя стукала в грудь, якобы ещё на эвм "наири" программировала решение уравнений. И поэтому программа должна работать вот так!
И конечно же все работало не так. Результат - пшик.

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

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

(57) Да, только у 1С всё таки органиченные возможности, и хотелки постановщика задач не всегда реализуемы(или реализуемы с большими трудозатратами) (55) а когда заказчик и начнет что либо требовать через суд, то отвечать будет как раз руководитель, т.к. тупому руководителю можно наврать все что хочешь (0) Если он не умеет кодить, то зачем он нужен? Руководить все с армии умеют )

(57) у меня финдир на молочном делае такой. Настраивал 6ку сам. потом я появился и 7ку все делал я. но он был в курсе возможностей 7ки и ставил задачи очено грамотно. Сам даже в екселе макросы пишет когда надо.

Так что достаточно чтобы человек был не дурак, и знал возможности инструмента. А быть конкретно спецом в 1с это не обязательно. Все должности выше ведущего прога, практическое знание 1с вообще не требует. более важно даже умение понимать бизнеспроцесс и описать его для ТЗ

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

Жесть, вначале тему прочитал как "Должен ли руководитель группы разработки 1С умереть. "

Должен хотя бы на минимальном уровне, чтобы понимать чем занимается то.

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

скорее не должен. но структуру конфигурации должен представлять хорошо.

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

Подводя итоги темы:

Всем кому я должен, я все прощаю ;-)

должен ли разработчик 1с знать бухгалтерию? - нет
Но как ты будешь внедрять и программировать для бухгалтерии если ты ее не знаешь?

Руководитель который не понимает в программирование как отдает задания?
ты напиши вот эту шняга, а ты вот эту?
Указания раздавать любой дурак может и наказывать за сроки тоже.

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

А если все программеры пошлют его нафиг и уволятся, кто тогда расхлебывать будет?

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

Не руководитель должен решать, регистр сведений или справочник использовать, а программист. Руководитель должен уметь поставить задачу и принять результат.

Должен в любом случае.
Объясню просто: приходит руководитель фин.отдела и начинает рассказывать небылицы, а потом просить это все реализовать в 1С. Если Рук-ль ИТ в разработке них.. не соображает, то звиздец команде разработчиков, которые работают под началом такого идиота. Работа превратится в вечный геморрой. Задача руководителя отдела ИТ на начальном этапе постановки задачи Заказчиком максимально выяснить все детали задачи, устранить нереализуемые хотелки (или найти им реализуемую альтернативу), и сформулировать задачу перед разработчиками, чтобы те поняли, что от них требуется. В противном случае - это лишнее звено между постановщиком задачи и ее исполнителем. умный и знающий руководитель не берется за невыполнимые и труднорешаемые задачи,
а неумный и незнающий руководитель берется - и часто достигает результата :)
(0) твои боссы сделали правильный выбор:) (66) ведущий прог- должность техническая. Ведущий прог он исполнитель, хоть и ведущий в комманде прогов. РП - это административная фигня. (73) а прогам не пофигу? это гемор того, кто дает задачу такую. да и вообще вы сильно преувеличили. в 1С можно сделать все что угодно, это некоторые проги утверждают обратное. (77) энтузиаст.
"1С можно сделать все что угодно" - не провоцируй толпу на ненужный холивар.. История знает тысячи примеров, когда в деятельности подчиненным давалось побольше полномочий, и результат был высокий, а также история знает примеры, когда грамотный руководитель непрерывно ходил и махал розгой над подчиненными, и результат был ужасным. (73) опять же вы в крайности впадаете. кодить уметь в 1с и знать 1с и ее возможности, вещи разные, Знание ТТХ танка например и реководство боем отделения танков совсем не подразумевает умение управлять танком. (80) почему-то все начинают рассматривать какие-то крайности в чем-то от чего принимаются неправильные решения и дело не движется. (77) Лично мне не пофигу. Если такой вот м..дак будет ставить мне невыполнимые задачи, а потом еще применять схемы мотивации по результатам выполнения, то он очень быстро отправится в далекое эротическое путешествие вместе с той компанией, где он работает. (77) "это гемор того, кто дает задачу такую". Нет, это гемор того, кто ее выполняет. Я свидетель. (0) должен. Другой вопрос насколько хорошо. Это зависит совмещает ли он собой функции ведущего прога или нет. (0)Ответ не так однозначен.
Кодировкой на скорости владеть не должен, но, должен знать все этапы разработки.

A team leader or team lead is someone (or in certain cases there may be multiple team leaders) who provides guidance, instruction, direction, leadership to a group of other individuals (the team) for the purpose of achieving a key result or group of aligned results. The team lead reports to a project manager (overseeing several teams). The team leader monitors the quantitative and qualitative result that is to be achieved. The leader works with the team membership

(83) Я не имею ввиду то, что РукИТ должен быть профессиональным программистом такого уровня, что сможет заткнуть любого подчиненного. Он должен быть знаком с решением, которое находится на поддержке, знать предметную область, и, несомненно, уметь руководить.

Он не должен быть кодером, и, уж тем более, не должен этого делать.

(77) Если задача не формализована, а то, хуже, неформализуема в принципе, или имеет в формулировке внутреннее противоречие, то её нельзя сделать ни на 1С, ни на каком-либо ином языке программирования.

(0) Однозначно должен. Может не на сверхъестественном уровне но выстраивать генеральную линию развития проекта нельзя.

З.Ы. Те кто пишет "Не должен" с логикой "Руководитель должен только руководить" - почитайте про менеджмент в компаниях IBM и Pepsi. - там у руля стояли то кондитеры то вообще фиг знает кто - результат - временные выпадения с лидерства в рынке.


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

Мастер-джедай. Какие компетенции нужны ведущему руководителю проектов?


Уметь работать с командой проекта - причем на этом этапе я бы даже добавила “виртуозно”:


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


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

Умение проводить изменения в команде в ходе проекта


Как я уже писала раньше, некоторое время назад я сдавала экзамен Professional Scrum Master (PSM I), проверяющий умение работать по правилам фреймворка Scrum. Формат экзамена следующий - за 60 минут надо ответить на 80 вопросов на английском. Проверять себя, сверяться с первоисточниками, гуглить и т. п. формально не запрещено, но в таком формате успеть мало реально - ты либо знаешь “правила игры по Scrum”, либо нет. Так вот, один из вопросов, который мне запомнился в этом тесте был про то, можно ли изменять состав команды, и в частности добавлять в нее новых членов в ходе проекта?
Правильным ответом вовсе не будет “нет, ни в коем случае”. Ибо мы с вами живем в реальном мире, имеем дело с живыми людьми и неожиданно всплывающими обстоятельствами. Кто бы мне год назад рассказал, что сегодня, когда я пишу эту статью, в июне 2020 года, наш мир будет выглядеть так, как он выглядит сейчас - я бы решила, что это сюжет плохого фантастического фильма - кстати, одна популярный канадский кинокритик опубликовала рецензию на COVID-19, где наглядно показала нелогичность сценария и нереалистичность сюжета… Так вот, независимо от наших намерений делать проект постоянной командой, команда меняться будет. Что здесь важно иметь в виду (кроме того, что стоит постараться минимизировать эти изменения)?
Здесь я вспомню, во-первых, правильный ответ на вопрос теста на Scrum-мастера, упомянутого мною выше: “Изменять состав команды можно при необходимости, но имейте в виду, что это вызовет кратковременное уменьшение продуктивности”.
Во-вторых. вспомню так называемый Второй закон Брукса: “Если проект не укладывается в сроки, добавление рабочей силы задержит его еще больше”.
Почему же так происходит? Ответ более менее понятен. Приходится вводить новых людей в курс дела, объяснять вещи всем уже очевидные, это займет ресурсы старых, ухудшится взаимопонимание в команде, и так далее.

На этом месте можно вспомнить стадии развития, которые проходит каждая команда (на русском их называют по-разному, но мне нравится вот такой перевод):

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

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

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

  • Максимально уменьшаем зависимость от того, что называется “bus factor” (автобусный фактор) - сколько человек из команды должно попасть под автобус, чтобы проект остановился? Стремимся к тому, чтобы информация была записана, а не хранилась в голове, чтобы на критичных участках могло работать несколько человек, а не один незаменимый, чтобы технологии передавались друг другу, а не оставались только у одного профессионала.
  • Предпринимаем осознанные усилия по тому, чтобы при включении нового человека помочь команде в новом составе максимально быстро и безболезненно пройти первые стадии развития группы, в частности:
    • Формирование - познакомить всех со всеми, организовать общение в неформальной обстановке и обсуждение, кто чем может быть полезен
    • Возмущение - замечать назревающие конфликты между участниками и помогать их разруливать всем вместе (не гасить, пользуясь властью, а именно - вместе разруливать)
    • Стабилизация - иметь записанные правила игры. Например, мы иногда использовали такой документ, как “Устав команды”, где в явной форме озвучены договоренности о принципах работы. Еще полезен такой документ, как “Матрица ответственности” (уже упомянутая мною в прошлой статье), где указывается, кто какими вопросами занимается и за какие задачи отвечает.

    Умение нанимать людей

    Про то, как определять потенциал людей уже в ходе найма - недавно наткнулась на интересный текст про набор , хочу процитировать:
    Я отбирал своих сотрудников сам. Рассказав, как много придется у нас работать, как мало мы за это будем платить и какие высокие требования предъявляем, я предлагал маленький тест. Набор из двадцати семи кубиков, никак не скрепленных между собой. Игрушка для детей 2–4 лет. Из него можно сложить большой куб с гранями три на три так, чтобы все грани были одного цвета. Например, красного. Или желтого. Или синего. Показывал его потенциальному сотруднику … рассыпал кубики и отходил в сторону. Люди работают так же, как играют. Через пятнадцать-двадцать минут я понимал все.
    … Человек, который собирает кубик того же цвета, который был изначально, более осторожен. Тот, кто выбирает другой цвет, — склонен к инновациям. И то и другое — нужные качества, но в разных ситуациях.
    … Интересно наблюдать и за процессом. Кто-то сразу приступает к сборке и просто берет кубик с подходящими гранями. Кто-то сначала анализирует, отделяет кубики с тремя гранями нужного цвета для углов, с двумя для ребер и уже потом начинает строить. Когда-то давно, когда знакомый психолог подсунул мне эту задачку, я сам начал первым способом, а потом, после неудачи, перешел ко второму. Знакомо, правда? Сперва попробуем по наитию, вдруг «прокатит». Не прокатило? Тогда читаем инструкцию.
    Все качества, проявленные в этой незамысловатой игре, нужны и полезны. Где-то надо вдумчиво анализировать, где-то быстро пробовать. Где-то нужна осторожность, а где-то бесшабашность, потому что если делать только то, что умеешь, ничему новому не научишься. Руководителю просто надо знать, какое дело кому поручить.
    (фрагмент текста от экс-руководителя компьютерной сети КЕЙ Олега Вайнберга)

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


    Как можно развивать этот навык?

    • Различные курсы, тренинги и литература по HR
    • На Инфостарте, в частности, проходит курс "Оперативное управление персоналом", его ведущую Елену Дуюн искренне рекомендую - сама у нее училась.

    Развивать людей в команде


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

    Как можно проверить, что руководитель умеет вдохновлять свою команду?

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

    Как можно развивать этот навык?

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

    Уметь отказываться от провального проекта


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

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

    Работать на уровне “программы” и “портфеля” проектов

    Что имеется в виду?

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

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

    Быть честным с заказчиком

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

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

    — А что сейчас не так с уровнем доверия?

    — Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…

    — А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.

    — Понимаете… Мы ему джуниор-инженеров продаем как синьор-инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.


    Вместо заключения



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

    По случаю того, что меня уже неделю как можно поздравить с получением статуса 1С:Руководитель корпоративных проектов, решила сказать несколько слов про то, как по моим представлениям, выглядит путь роста и развития руководителя проектов 1С. Подробнее про это я планирую поговорить на бесплатном вебинаре “Путь джедая в управлении проектами 1С”, в четверг в 17:00 МСК.


    Сертификация 1С:Руководитель корпоративных проектов, вслед за тестированием 1С:Управление проектами и знакомством с шаблонами от 1С из Профкейса, в очередной раз укрепила меня в понимании, что 1С не ставит себе целью проверить умение проекты внедрения реализовывать. А проверяет формальное соответствие технологии - процедуре. Это не хорошо и не плохо, это данность. В конце концов, 1С тоже можно понять - им важно быть уверенным, что вы все делаете формально соблюдая технологию. А тот факт, что вы всё делаете фактически хорошо - пусть заказчик и ваше руководство проверяют. Они в этом куда более заинтересованы. На этом месте мне вспомнился один из тезисов Владимира Тарасова, руководителя “Таллиннской школы менеджеров”. Тарасов много рассуждает, что в нашей профессиональной карьере, также как и на жизненном пути, определяющее значение имеют два умения, и нужно уметь их идентифицировать, и различать. А именно “умение быть” - то есть реально делать работу хорошо. И “умение казаться” - то есть производить впечатление хорошей работы. Какое из умений важнее? Вообще-то, “умение быть” - ибо важен в первую очередь результат. Но без “умения казаться” ваша хорошая работа рискует остаться незамеченной, и поддержку без него тоже получить непросто. А что произойдет, если ваше “умение казаться” существенно опережает ваше “умение быть”? Вы имеете все шансы произвести хорошее впечатление и пустить пыль в глаза. Но ваш головокружительный успех будет недолгим и, скорее всего, в длительной перспективе вызовет не менее головокружительное падение, если вы не дополните свое красивое “умение казаться” менее зрелищным, но более необходимым “умением быть”.
    Итак, какое же резюме? Важны оба умения, и зазор между “быть” и “казаться” должен быть небольшим. Так вот, как показывает мой опыт, сложные и красивые документы и статусы, подтверждают в первую очередь именно “умение казаться”. И в моей жизни, увы, мне неоднократно приходилось видеть в организация красивые и грамотно написанные регламенты и отчеты, имеющие к действительности весьма смутное отношение.
    Поэтому сегодня я хочу поговорить именно про развитие “умения быть”. То есть, как надо проектами управлять, чтобы продукты внедрялись, заказчики оставались довольными, команда была не взмыленной, функционал был именно тем, какой нужен. А не чтобы бумажки были красивыми. Вот про это “умение быть” руководителем проекта и пойдет здесь речь. Сразу оговорюсь, очевидно, что предлагаемый мною маршрут не является единственно верным и единственно возможным. И осуществим он только в условиях поддержки организации, а не так, как вот в этом комиксе.


    И вообще, всё нижеизложенное - только мое скромное мнение. Дополняйте своими точками зрения.

    Итак, как может расти руководитель проекта, и как будет выглядеть его тернистый путь профессионального развития?

    Младший-джедай, подающий надежды

    Как рассказал нам однажды Лев Новоженов на встрече с юными журналистами - человек, пришедший на телевидение, сначала должен несколько лет “мыть туалеты”, а потом уже предлагать идеи и, тем более, принимать решения. Потому что иначе подавляющее большинство его идей и предложений будут страшно далеки от реальности. Вот также и человек пришедший в управление 1С-проектами подкованный теоретическими знаниями, даже высококлассными, плохо подходит на эту роль. Гораздо правильнее и перспективнее сначала поработать в команде в роли бизнес-аналитика, разработчика, и т. п. И когда вы хорошо представляете внутреннее содержание проекта, технологию, бизнес-процессы и т. п., вы будете готовы к следующему шагу.

    Какие навыки самые главные для РП-ученика-джедая?

    • Знание прикладных решений
    • Умение работать в команде
    • Продвинутые навыки в своей сфере (аналитика/разработка - смотря из кого данный руководитель проекта пытается вырасти)
    • Базовые навыки в смежных сферах (аналитика/разработка/администрирование)

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


    Падаван


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

    Какие навыки самые главные для РП-падавана?

    • Всё то, что важно для ученика-джедая - никуда не делось
    • Представление о том, какие бывают подходы к управлению проектами (чем проект отличается от техподдержки)
    • Знакомство с технологией управления проектами (хотя бы одной, желательно - принятой в компании, если она есть)
    • Базовое умение руководить людьми (умение завоевывать авторитет, умение делегировать задачи, контролировать)
    • Умение договариваться - с бизнес-заказчиками, командой, руководством
    • Умение управлять проектом в созданных для этого условиях
    • Умение учиться и перенимать опыт. Одним из критериев, что падаван готов к переходу на следующий уровень, на мой взгляд, будет переход из стадии “Начинающего энтузиаста”, который уверен, что есть крутые методы, которые позволят всех победить в стадию “Утратившего иллюзии ученика”, который понимает, что легко и просто не бывает, и нет предела совершенству.

    Рыцарь-Джедай

    Начну с анекдота.

    Встречаются двое коллег:
    – Как твои успехи в управлении проектами?
    – Я уже провалил три проекта!
    – О, значит ты уже опытный руководитель проектов.

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

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

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

    Какие навыки самые главные для Рыцаря-Джедая?

    • Умение применять (как минимум одну) технологию управления проектами в руководстве проектами, и уметь с ее помощью реализовывать проекты в срок, в рамках бюджета и к удовлетворению заказчика
    • Опыт руководства, во-первых успешным проектом, во-вторых, проектом проваленным или столкнувшимся со сложностями
    • Умение формировать и мотивировать команду
    • Умение разрешать конфликтные ситуации с заказчиком
    • Умение учиться на ошибках и совершенствовать свои компетенции от проекта к проекту
    • Умение работать с большинством главных инструментов управления проектами:
      • Устав - документ, закрепляющий договоренности с ключевыми участниками
      • План проекта - создавать план, следовать плану, отслеживать отклонения и вносить необходимые коррективы
      • Матрица ответственности - инструмент для определения, кто за какие задачи отвечает
      • Ретроспектива - инструмент для сбора обратной связи и пополнения базы извлеченных уроков
      • Отчеты по ходу работ - как известно, управлять мы можем только тем, что мы можем измерить

      Мастер-Джедай


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

      Магистр-Джедай


      Магистр Джедай - это член совета джедаев. То есть это не просто тот, кто руководит проектами, спущенными сверху, а тот, кто способен принимать решение, какие именно ИТ-проекты нужно запускать. В проектном управлении, как известно, есть два уровня “do the thing right” - “делай вещи правильно” - про умение хорошо управлять проектами.
      И уровень “do the right things” - “делай правильные вещи” - про умение хорошо выбирать, какие проекты стоит запускать. Потому что если продукт успешно внедрен, но не дал требуемого бизнес-эффекта - неуместно обвинять в этом руководителя проекта, это не его забота. А забота того, кто принимал стратегические решения - включить именно эти проекты в портфель проектов.


      Гранд-мастер ордена Джедаев


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

      Summary


      Еще раз, краткое резюме основных тезисов:

      • Умение делать работу важнее умения красиво ее описывать. (“Быть” важнее, чем “казаться”). Но последнее тоже важно.
      • Хорошие руководители проектов получаются из компетентных членов команд
      • Стоит представлять не только свою сферу компетенций, но и смежные сферы
      • Работа с командой важнее и сложнее работы с документами
      • Поддержка организации крайне важна для успешного руководства проектами
      • Опыт неудач и проблем столь же важен для развития, как и опыт успехов
      • Нет предела совершенству.

      Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах

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

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

      Я собираюсь рассказать о нашем опыте использования типового решения фирмы «1С» «Система проектирования прикладных решений» (сокращенно СППР) в нашей компании. Я буду говорить в контексте разработки на платформе «1С:Предприятие», хотя СППР в нашем случае используется и для других задач. Тем компаниям, которые уже успешно используют СППР, либо другие системы, возможно, тоже будет интересен наш опыт.

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

      Какие проблемы возникают при разработке программного обеспечения?

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

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

      • о том, какие изменения были произведены;
      • о том, зачем конкретное изменение в программе было сделано;
      • и о том, кто принимал решение для того, чтобы это изменение попало в программу.

      Быстрый поиск таких вещей очень облегчает жизнь.

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

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

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

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

      • Кто сейчас чем занимается,
      • Сколько времени тратится,
      • Почему на это тратится столько времени,
      • И что мы можем с этим сделать.

      Без инструментов отражения времени, потраченного на ту или иную задачу, сделать это будет очень сложно.

      Зачастую учет времени нам необходим и для бизнеса, когда бизнес спрашивает отдел информационных технологий: «Чем вы занимаетесь, почему потратили столько времени на реализацию этой функции?». Гораздо удобнее открыть отчет и в готовом виде предоставить его бизнесу.

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

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

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

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

      Почему СППР? Возможности СППР «из коробки»

      Почему СППР? Для нашей компании здесь все достаточно просто.

      • Я и мои руководители уже имели опыт работы с этим программным продуктом, а это очень важно.
      • Правила разработки, которые мы придумали у себя в ИТ-отделе, очень удачно ложились на методики, которые уже были реализованы в СППР.
      • Также немаловажную роль сыграло то, что мы сами – 1С-ники, любой из нас мог доработать этот программный продукт.
      • Развернуть конфигурацию СППР очень просто – это можно сделать за пару часов. Достаточно выполнить минимальный набор настроек – все остальное можно донастроить под себя в дальнейшем.

      Возможности, которые вы получаете в СППР прямо «из коробки»:

      • Проектирование
      • Ведение документации
      • Совместная работа
      • Распределение задач
      • Обработка ошибок
      • Учет трудозатрат

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

      Основные объекты СППР и их взаимосвязи

      Вернемся к объектам, которые заложены в СППР и поговорим о том, как они решают вопросы и проблемы, обозначенные ранее.

      На этой схеме мы видим основные объекты СППР и их взаимосвязи . Это:

      Это – обзорная схема, а дальше я расскажу по каждому объекту, для чего он используется. Вам станет понятнее, насколько СППР может быть применима для решения ваших задач.

      Требования

      Требования – это входящая информация, которая поступает в ваш отдел.

      Технический проект

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

      • Планирование сроков
      • Контроль разработки
      • Связь с требованиями и ошибками
      • Коллективная работа
      • Отдельная поставка

      Что может являться основанием для создания технического проекта?

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

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

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

      Управление техническим проектом по контрольным точкам

      Что есть интересного в техническом проекте?

      • Технический проект разделен на этапы, контрольные точки , которые он проходит в своем жизненном цикле. Например:
      • Открытие проекта;
      • Подготовка концепции;
      • Проектирование;
      • Реализация;
      • Тестирование и т.д.
      • При создании технический проект автоматически заполняется списком контрольных точек из настроек СППР.
      • Этот список можно гибко менять – например, если у вас технический проект на исследование, и разработки в нем не предполагается, вы можете какие-то контрольные точки пропускать.
      • Чтобы пройти контрольную точку, в СППР существует механизм согласования , т.е. для каждой контрольной точки при настройке СППР устанавливаются роли и участники, которые будут согласовывать данную контрольную точку. Простой пример: контрольная точка, связанная с окончанием разработки. Здесь принимают участие два человека – это может быть руководитель отдела, который утверждает, что технический проект реализован, и технический лидер, который, например, проводит код-ревью проекта. И как только эти два человека согласуют контрольную точку проекта, считается, что она пройдена. Вы можете очень гибко настраивать согласование этих контрольных точек в зависимости от специфики вашей разработки.

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

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

      Ошибки

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

      Функции, заложенные в механизм обработки ошибок в СППР, позволяют делать с ошибкой многое:

      Учет фактических трудозатрат

      Перейдем к учету трудозатрат. Основные требования к нему:

      • Позволяет легко отражать затраченное время
      • Детализирован до технического проекта, задачи, ошибки
      • Позволяет добавлять произвольное описание выполненных работ
      • Возможность получения оперативных данных

      В типовом решении есть отражение трудозатрат на задачу, запланированные и согласованные трудозатраты. Но мы пошли немного дальше и реализовали свой механизм учета трудозатрат :

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

      Ввод информации о трудозатратах – это не самоцель. Целью является оценка того, как мы тратим свое время. Это очень важно.

      Читайте также: