ПРОЕКТ БЫЛ ПРИНЯТ

Клиенты часто обращаются к IT-студиям с просьбой взять проект на поддержку и развитие. В сфере разработки сайтов и мобильных приложений это очень распространённый и очень непростой случай. Редактор компании Лайв Тайпинг Андрей Руденко поговорил с коллегами, чтобы узнать о возможных сложностях, и понять, что нужно сделать, чтобы обе стороны остались довольны и долго работали вместе.

Саппорт как тенденция

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

Раньше мы дорабатывали и поддерживали только те проекты, которые делали для клиентов сами. Около года назад мы поняли, что их уже достаточно много, сформировали в компании отдел техподдержки, прописали процессы работы и реагирования на запросы клиентов и начали принимать на поддержку проекты, разработанные другими командами. Сейчас мы поддерживаем и развиваем около 20 проектов наших клиентов, среди которых треть — изначально не наша разработка. К таким относятся мобильное приложение для заказа туристических услуг RocketGo и приложение для удалённых консультаций по вопросам здоровья.

Почему проекты передают на доработку

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

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

Основные вопросы

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

Немногие компании прежде публиковали свои соображения о том, в каком порядке производить приём чужого проекта. Одной — если не единственной — из них стала школа менеджеров «Стратоплан». В своём вебинаре Иван Селиховкин приводит алгоритм, состоящий из семи вопросов:

Полностью вебинар можно посмотреть здесь.

Из чего складывается грамотный приём проекта

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

Старая команда

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

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

Code review

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

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

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

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

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

Приёмочное тестирование

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

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

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

ВАЖНО! Все устные и письменные обсуждения также фиксируются. Логи встреч и переписок — это адвокаты обеих сторон.

Приёмочное тестирование не вскрывает всех проблем проекта. Чтобы всецело постичь код, команде нужно начать кодить. Именно кодить — code review может закончиться только тем, что разработчики скажут: «Ок, мы знаем, что делать». Но внедрение новых функций и работа с зависимостями — это уже другая история.

SLA

SLA (Service Level Agreement, или «соглашение об уровне услуг») — это документ, регламентирующий рабочие отношения клиента и поддержки. В нём прописывается ситуация, в которой потребовался этот документ, объём поддержки (количество часов в месяц), роли на проекте, время реакции в зависимости от статуса задачи (критическая, срочная, обычная), что будет результатом реагирования, а также как планируется и оплачивается время руководителя проекта, разработчика, тестировщика, аналитика и дизайнера.

Работа по SLA — это результат переговоров. Менеджер предлагает выбрать из двух условий: либо клиент платит деньги за поддержку по схеме Time & Material (и это значит, что задача может быть выполнена когда угодно в границах оплаченного времени), либо работа идёт по SLA и клиент платит абонентскую плату (и это значит, что команда бронируется на конкретное количество часов).

В формате устной договорённости такие вещи оставлять нельзя.

Смысл продукта

Как code review с технической стороны, команда со стороны бизнес-модели и процессов продукта должна вернуться к «исходной стадии» и получить ответы на ключевые вопросы:

Возможно, клиент вот уже очень давно ушёл совсем не туда со старыми командами. Задача новой команды — найти правильный путь, поверить в этот путь и передать эту уверенность клиенту.

А ещё клиенту нравится,.

Медленная реакция на запросы

Это то, что не может не бесить клиента. Но скорость реакции — понятие относительное. Граница опять таки проводится в SLA: пропишите время реагирования на клиентские запросы, и ответ через два часа в случае критической ситуации в рабочее время уже не будет медленным, если оговорено именно такое время. Бывают перебои в соединении, природные катаклизмы и прочее, но мы обсуждаем штатные ситуации.

Несовпадение ожидания с реальностью

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

Работа с чужой командой

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

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

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

Фрилансеры! Наши представления о вас базируются только на нашем же опыте работы с вами. Если вы в гневе от прочитанного, если вы не узнаёте себя в этих утверждениях и считаете сказанное наглой крамолой — смело пишите об этом в комментариях. И Лайв Тайпинг, и наши коллеги из других студий будут рады работать с качественно другими фрилансерами: мотивированными, не выдающими джуниорский результат за плод 16-часовых усилий, готовыми стать полноценными членами команды. Обратите на себя внимание!

Вывод

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

Всё начинается с вопросов клиенту:

После этого менеджер и клиент оговаривают время, которому команда уделит знакомству с кодом. Неделя, две или месяц — срок зависит от размеров проекта.

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

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

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

Прогнозировать сроки нужно с учётом возможных рисков, о которых должен знать клиент.

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

Время на прочтение

На GitHub размещены миллионы Open Source проектов, но для начинающих разработчиков бывает достаточно сложно поначалу разобраться в принципах их работы, а также в интерфейсе сайта. Это краткое руководство поможет участвовать в проектах с открытым кодом, которые размещаются на GitHub.

Адаптированный перевод статьи The beginner’s guide to contributing to a GitHub project. Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.

Перевод был сделан для платформы курсов по программированию Хекслет

Выберите проект

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

Создайте рабочую копию на своем компьютере

Прежде всего, вам нужен локальный форк проекта, поэтому нажмите кнопку «Fork» в GitHub.

Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:

Теперь вам нужна локальная копия, найдите «SSH clone URL» — справа, вверху. Как настроить ssh-доступ к GitHub вы можете узнать на Хекслет в беплатном курсе Введение в Git

Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться — на Хекслете есть большой курс по базовым командам в командной строке.

Результат будет выглядеть примерно так:

Перейдите в директорию нового проекта:

$ cd hexlet-sicp

Теперь необходимо установить связь локальной копии с оригинальным проектом, чтобы вы могли получать изменения основного проекта и вносить их в свою локальную копию. Сначала перейдите по ссылке в оригинальный репозиторий — она помечена как «forked from» в верхней части страницы GitHub. Это вернет вас на главную страницу проекта на GitHub, где вы сможете найти «SSH clone URL» и использовать его для создания новой связи, которую мы назовем upstream.

Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:

Заставьте его работать на вашей машине

Теперь, когда у вас есть исходный код, запустите его на своем компьютере. Надеюсь, в файле README или INSTALL этих проектов будет документация, как это сделать.

Сделайте что-нибудь полезное

Это самый приятный этап — внести свой вклад в проект. Начните лучше c исправления ошибки, которая вас раздражает. Либо найдите подходящую в трекере проблем проекта — «Issues». Если вы не уверенны, с чего начать, многие проекты используют ярлык «good first issue» (или его разновидность), чтобы указать, что эту проблему может решить даже новичок в проекте.

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

Ветвление

Важное правило — размещать каждую часть разработки в отдельной ветке. Изучите, какая модель ветвления используется в проекте. Если в документации бранч-стратегия не описана, посмотрите, как называются уже существующие ветки. Вы можете назвать свою ветку как угодно, но важно, чтобы она была осмысленной. Названия веток типа «feature», «bugfix», «hotfix», «update» с указанием на то, что меняется — это лучший вариант.

В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:

$ git checkout master
$ git pull upstream master && git push origin master
$ git checkout -b readme-update

В первую очередь мы убеждаемся, что находимся на master-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую ветку readme-update.

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

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

Убедитесь, что вы исправляете только то, над чем работаете. Не поддавайтесь искушению исправить другие вещи, которые вы видите по пути, включая проблемы форматирования, так как ваш PR, скорее всего, будет отклонен.

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

Создайте Pull Request

Чтобы создать PR, вам нужно отправить ветку в ваш форк на GitHub, а затем нажать несколько кнопок на GitHub.

Чтобы отправить новую ветку:

$ git push -u origin readme-update

В результате будет создана ветка в вашем проекте на GitHub. Флаг -u связывает эту ветку с удаленной, так что в будущем вы сможете просто набрать git push origin в терминале.

Вернитесь в браузер и перейдите к вашему форку проекта (в нашем примере это будет выглядеть вот так, и вы увидите, что ваша новая ветка появилась в верхней части с удобной кнопкой «Compare & pull request»:

Нажмите эту кнопку!

Если вы видите выделенную надпись, как показано ниже:

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

На этой странице убедитесь, что «base repository» и «base» указывает на правильный репозиторий и ветку. Затем дайте хорошее, краткое название вашему запросу и объясните, почему вы его создали в поле описания. Добавьте соответствующие номера проблем, если они у вас есть.

Если вы прокрутите страницу немного вниз, вы увидите diff с вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.

Как только вы будете уверены, нажмите кнопку «Create pull request» и все — готово.

Проверка разработчиками проекта

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

Зачем и как нужно ревьюить код, вы можете посмотреть Вебинар о код-ревью: зачем он нужен, как оптимизировать код и как делают в Skyeng.

Итоги

Главные этапы работы в Open Source:

Дополнение от переводчика

Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.

Скоро лето. А пора отпусков началась уже сейчас. Разработчиков не так сложно распределять по проектам, особенно когда работа построена как у нас — спринтами. Другой вопрос с менеджерами. П М на каждом проекте один. И он тоже хочет в отпуск. Проблема.

Ах, да. Проект же можно оставить в руках ПМа на время его отпуска. Пусть руководит работами с ноутбука, лежа на пляже. Только так не работает. У нас менеджеры ходят в полноценные отпуска. Так что приходится что-то делать с проектами (причем со всеми, поочередно) на это время.

Вообще, на случай, если проект очень большой, сложный (ну, или клиент такой) — у нас в договоре есть пункт:

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

График отпусков и командировок ответственных лиц:

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

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

Как именно передавать проект — зависит от этапа на котором он находится.

Итак, фазы на которых может оказаться проект

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

Демонстрация результата работ заказчику обычно не проводится (если позволяют сроки) до выхода руководителя проекта из отпуска. Если сроки не позволяют — то промежуточные результаты контролируются дополнительно директором по юзабилити / арт-директором. Демонстрации проводит аккаунт-менежер совместно с аналитиком.

Проект более-менее стандартный, в активной стадии разработки

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

какие работы должны быть сделаны и когда,

что и когда должно быть согласовано с заказчиком,

какие и когда счета / акты должны быть выставлены. Если на каждый этап работ по проекту готовится отдельное приложение к договору — оно должно быть заранее подготовлено, чтобы его можно было просто взять и отправить заказчику в запланированные сроки (с минимальными изменениями, если корректировался бэклог).

Задачи сразу проставляются в календарь и кор.портал всем исполнителям (захочешь — не забудешь).

Сложный проект с нестандартной логикой работы, техническим заданием на 200 страниц, по которому идет 12-ый спринт программирования. Отклонения от технического задания можно отследить только по бэклогам спринтов.

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

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

Проект на стадии сдачи и подписания итогового акта

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

Проект на стадии гарантийной и технической поддержки

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

Порядок действий при передаче проекта

Итак, проект успешно передан. Менеджер отдохнул и вернулся из отпуска, даже на работу уже пришел. Что дальше? Каждый ответственный в том же документе отдельной колонкой заполняет статус по проекту на момент обратной передачи + кратко обсуждает это с ПМом голосом. Клиенту уходит письмо «Здравствуй, Вася». Дальше все идет своим чередом.

Новый проект для менеджера или с чего начать?

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

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

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

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

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

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

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

Теперь немного практических примеров. Когда я устроилась работать в Константу, мне ребята честно сказали: “Катя, у нас хаос, процессов нет, но мы даем тебе полный карт-бланш на изменения”. Хм, для меня звучало очень интересно. Это была хорошая возможность отточить свои навыки, ведь нужно было выстроить процессы с нуля. Перед выходом я начала накидывать в голове план того, что мне нужно будет сделать, ведь сразу после выхода на меня свалится большое количество работы: изучить продукт, построить дружеские отношения с командой и руководством, понять внутренние и внешние процессы проекта, подхватить текущие планы работы и т.д.

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

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

Ниже примеры схем, которые я рисовала в Миро.

Задача на разные платформы

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

Сбор фидбека от команды

3. Отношения с командой. Проект — это, в первую очередь, люди, и нужно знать, с кем вы работаете. У каждого менеджера свой подход: кто-то может первым делом начать читать документацию (но что делать в случае, если ее нет?) или изучать задачи в беклоге, но для меня, как для менеджера, все решают хорошо выстроенные отношения с командой. В сложных и срочных вопросах именно люди подхватят и затащат. Правильно выстраивая хорошие отношения с ребятами, я чувствую уверенность в том, что они не подведут во время важного релиза, и мы вместе сможем сделать практически все. Как выстраивать отношения — опять же вопрос общения, умения слышать и быть гибким. Общие встречи, 1-to-1 — попробуйте узнать свою команду не только с рабочей стороны, но и с более личной, лишний раз поинтересуйтесь: “Как дела?”, и вы можете быть удивлены, насколько людям важно, что их дела кому-то не безразличны. Да, наверно, я говорю банальные вещи, но даже самое очевидное бывает не очевидно.

4. Вопросов много не бывает. Это правило, которому придерживаемся мы в Константе — задавайте вопросы. Много вопросов. Не думая, глупые они или нет. Чем глубже копнете на начальном этапе, тем лучше вы начнете понимать проект и решать более сложные задачи в дальнейшем. Важный момент: в команде нужно выстроить доверительные отношения, чтобы каждый понимал — его никто не осудит за вопрос, даже если тот окажется элементарным или нецелесообразным.

5. Позиция «знаю, что ничего не знаю». Совсем не рекомендую в новый проект тащить устои со своего предыдущего места работы просто потому, что вы привыкли так работать, и там ЭТО РАБОТАЛО. Не торопитесь вводить новые правила, регламенты и процессы, вы успеете это сделать. Вначале я досконально изучала то, как сейчас работает команда, и на основе полученной информации, совокупности имеющихся у меня навыков и опыта, я потихоньку предлагала команде изменения и старалась улучшить и облегчить процессы. Ваша новая семья не знает, в каких процессах и правилах вы работали до сегодняшнего дня 🙂

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

Спасибо за внимание, желаю всем классных проектов и новых горизонтов!

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

К сожалению не выходит выложить на сайт инструкцию в картинках с хорошим разрешением, текст плохо читаем.

Файл с читаемой инструкцией для скачивания: https://cloud.mail.ru/public/kEwf/bPLdDcA2N

Как подать заявку на технологическое присоединение через портал-тп.рф

Заходим на сайт https://портал-тп.рф/platform/portal/tehprisEE_portal

В правом верхнем углу нажимаем на кнопку «Личный кабинет»

Указываем электронную почту, телефон, пароль, фамилию, имя и принимаем условия.

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

Обратите внимание! Во вкладке «Общие» необходимо подтвердить контактный номер телефона. Это необходимо сделать для того, чтобы приходили СМС по статусу заявок. Ниже рисунок с подтвержденным адресом электронной почты и номером телефона.

Подача заявки на технологическое присоединения

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

Выбираем в верхней строке «Другой регион» если автоматически регион Тульская область не подтянулся.

В нижнем левом углу нажимаем кнопку » Подать заявку»

Далее заполняем все вкладки: «Заявитель», «Вид присоединения», «Энергопринимающие устройства», «Энергосбытовая организаия», «Прочие сведения» и «Документы».

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

Во вкладке «Вид присоединения» выбираем, тип присоединения — присоединение по постоянной схеме, подключение – Новым присоединением (см. рис.)

Далее во вкладке «Энергопринимающие устройства» выбираем Наименование устройств – Малоэтажная жилая застройка, Местоположение – кадастровый номер. Местоположение устройства не совпадает ни с одним из адресов заявителя, ставим галочку – Точный адрес отсутствует, выбираем субъект РФ – Тульская область и вписываем адрес в точности как указан в документах на право собственности участка.

Заполняем технических характеристики устройства

Максимальная мощность — 15 кВт, при напряжении — 0,4 кВ, Категория надежности – третья, Характер нагрузки – Бытовая

Во вкладке «Энергосбытовая организация» выбираем наименование – АО «ТНС энерго Тула», Вид договора – Договор купли-продажи электроэнергии, Ценовая категория – первая ценовая категория.

Заполняем вкладку «Прочие сведения»

Способ внесения платы – Единовременный платеж, Способ обмена документами – Электронное взаимодействие, Способ уведомления – SMS уведомления

Далее переходим на вкладку – «Документы»

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

Далее жмём кнопку «ОТПРАВИТЬ».

Если все сделано верно, заявка отправиться в Тулэнерго, а Вам придет СМС с номером заявки и статусом – Заявка поступила.

Далее ожидаем статус «Заявка принята в работу (подготовка проекта договора и ТУ)» — это означает, что Ваша заявка принята, первый шаг пройден.

Следим за приходящими на телефон СМС от Россети о изменении статуса заявки на «Проект договора на рассмотрении заявителя». Заходим в личный кабинет во вкладку «Исполнение заявки». Там должны появится: договор на ТП, Инструкция и технические условия.

Переходим во вкладку «Оплата». Если в этой вкладке не отображается файл со счетом на оплату, нажимаем кнопку «Обновить данные»

После обновления должен появится файл на оплату (смотрим рисунок ниже)

В правом углу должен появится файл со счетом на оплату. Так же можно оплатить онлайн нажав на кнопку, находящуюся слева «Оплатить».

ВНИМАНИЕ! Счет должен быть оплачен в течении пяти дней. После оплаты счета, договор считается подписанным.

Далее ожидаем установки счетчика. Счетчик сетевая организация по договору должна поставить в течении шести месяцев, но на практике они в эти сроки не успевают и приходится напоминать частыми звонками (тел. +7 (487) 662-26-50) о необходимости соблюдать обязанности по договору.

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

Председатель СНТ № 24 «Машиностроитель – 2» Федосов Андрей Анатольевич тел. +7 (903) 769-92-72

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

Привет! На связи Ирина Санарова, Head of PMO в Creonit. Разрабатываем цифровые сервисы. Мы много внимания уделяем внутренним процессам и менеджменту, так как выстроенные процессы позволяют гарантировать заказчикам выполнение проектов качественно и в срок, а руководителям проектов — эффективно координировать работу команды на проектах.

Я постоянно общаюсь с руководителями проектов в неформальной обстановке, а также провела сотни собеседований на эту позицию. Часто я слышу от руководителей о таких болях:

Из-за этого менеджеры чувствуют себя перегруженными задачами и обязанностями, что приводит к демотивации и выгоранию. Но почему эти проблемы возникают и что с ними делать? Чаще всего они возникают из-за 4 базовых проблем, которые мы разберём в этой статье. Я расскажу о базовых знаниях, которые помогут руководителям достигнуть успехов в управлении любыми проектами.

Обзор распространенных ошибок в работе руководителей проектов

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

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

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

Первая задача руководителя проектов — организовать себя и свой рабочий день.