Тим

Как правильно релизиться в больших компаниях?

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

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

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

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

Все дело не в инструменте а в подходе. Ты пытаешся управлять слишком большим количеством людей. Эффективное количество подчиненных это 3-7 в зависимости от твоих навыков.

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

Так удобней работать и более результативней.

И не знаю слышал ли ты что то про Scrum, если нет то читай. Твоя роль - Product Owner.

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

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

Путь к успеху:
0. Найти ментора где тебя обучат. На тематических форумах по АЙТИ часто есть топики о поиске менторов где можно оставить свой пост и надеятся на результат. Может повезти.
1. Гуглим
- Сюхари
- Эмпиризм
- Цикл Деминга
2. Лирика
Книги:
- Черная Книга Менеджера (Слава Панкратов)
- 45 Татуировок Менеджера (Макс Батырев)
- Цель (Элияху Голдрат)
- Идеальный руководитель (Ицхак Адизес)
Фильмы:
- Мне бы в небо (Жорж Клуни)
- Уолт Стрит (1987)
- Социальная Сеть (про фейсбук)
- Steve Jobs (с эштоном катчером)
- Марсианин (как мет деймон выращивал картошку)
(смотри в любом порядке, но рекомендую начать с мне бы в небо, затем стив джобс и затем социальная сеть. когда будешь смотреть, каждые 5 минут задавай себе вопрос - почему то что я смотрю полезно мне как менеджеру. будешь замечать поразительно полезные вещи)

2. Приобретаем теорию:
- Agile
- Kanban
- Scrum
- Lean Startup
- Lean Production
- PMBOK(6 издание) (для начала учим оглавление, и читаем описание каждого оглавления. затем читаем чуть глубже тот раздел который наиболее понятен. логику и порядок искать не нужно, его там нет. важно использовать эту книгу как пример для действия когда совсем непонятно что делать, и лучше уж как то чем никак, а не как конкретно план и единственно верный метод)
3. Смотрим на ютюбе:
- Эффективные коммуникации (например старые видосы Радислава Гандапаса за 2000 года. ни в коем случае не смотреть новые, он слился)
- Если Вова их еще не стер, посмотреть MS Project 2013 видосы от Владимир Иванов
- Поискать на торентах все видосы недавно двинувшего кони Стратоплана. Там кажись толи 500 толи 900 часов материала. Можно рандомно включать когда делать нечего, что бы просвещаться.
4. Смотрим и тыкаем инструменты, ищем на ютюбе какие то гайды и лайфхаки
- Gmail
- Google Calendar
- Word, Excel, Powerpoint (а так же всё тоже самое только гугловое)
- Google Drive/Dropbox
- Trello
- Redmine
- JIRA
- Confluence
- Slack
- Hangouts/Skype/Join.me/Zoom
5. Найти вакансию associate project manager или trainee project manager в какой то большой галере где хотя бы 1000+ человек. Если не получается, junior project manager, assistant project manager или project manager assistant. Если всё еще не получается, то знать Scrum, учиться ему и смотреть видосы по фасилитации. Когда поймешь и научишся фасилитировать, начинаешь искать работу скрам мастером (Scrum Master).

Знаком с десятком собственников которые держат аутсорс-аутстаф компании (Украина, Беларусь). При штате 30-100 человек, чистая прибыль составляет от 5 до 20% прибыли. Больше всего прибыть при меньшем количестве сотрудников, так как чем больше сотрудников тем больше расходы на офисы, отпуска и поддержание софта и сервиса в адекватном виде. Доходы у среднего аутсорсера в 30-50 человек в мобилке и вебе около 1-2 миллионов в год при рейте 25-30$ / ч. Средняя загрузка по программистам 60-80%, то есть 40-20% всегда в простое и ожидают новых проектов/никуда всунуть.

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

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

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

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

Начинайте с фундамента, судя по вопросу, он у вас не построен.

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

ganttic.com

Может помочь. Пользуюсь что бы иметь картину на ком какой проект, кто болеет, и т.п.

СТО отвечает за техническое исполнение проекта.
ПМ отвечает за исполнение проекта.

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

ПМ ставит задачу на разработку - она проходит через процесс который выстраивает СТО и на выходе ПМ получает желаемый результат.

Назовите его хоть куском дерьма. Главное что бы внутри было то чего хочет ваш руководитель.

Что значит по должности?

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

Если в проекте нет маркетинг офицера либо ПМ выше его, то это провал. Любой продукт который нацелен на заработок средств управляется маркетингом.

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

Как всегда и везде, люди не до конца изучили agile/scrum и что то постят..

Ни где четко не прописано что заказчик должен быть вовлечен в процесс.

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

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

Если мы говорим о настоящем Agile Scrum, то собираем команду, изолируем её от всего кроме нашего проекта и дальше по методологии:

(тут есть только 2 простейших процесса где нужен заказчик на 1-2 часа в 2 недели. типичная ошибка, звать его везде как этому учат на дурацких тренингах за 1000$)

1. Собираем с заказчика хотелки и пихаем в беклог
2. Собираемся и грумим беклог дробя эпики на мелкие стори или еще мельче эпики
3. Делаем спринт пленинг и дробим беклог на задачи, поочередно оценивая всё
4. Согласовываем инкремент и какой Definition of Done
5. Работаем итерацию попутно проводя дейли статус митинги для синхронизации статусов и раннего выявления проблем
6. Демонстрируем в конце что получилось, собираем от заказчика фидбек и форматируем беклог, возвращая в него то что не готово и все что не влезло в спринт
7. Делаем ретроспективу и убеждаемся что копаем в нужном направлении и не делаем ничего лишнего либо добавляем в процессы работы то что стоило бы делать
8. Возвращаемся к пункту 1

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

Когда вы начинаете оценивать стоимость и сроки проекта под Agile/Scrum вы наступаете на теже грабли. Если заказчик не знает на что он идет то это не Agile.

Наши клиенты уже с шишками и готовы платить деньги не представляя стоимости проекта в целом и тем более его сроков. С большего это стартапы. На опыте запуски и провалы хороших проектов. Один из них уже 4й год на рынке и поднял 20 лямов инвестиций в США и сейчас является одним из успешных интернет магазинов в США.

Изначально на кармане у заказчика было денег понты и работало 2 человека на проект - бекенд и айос и копали-копали пока не выросли до постоянной команды в 5 человек (бекенд, фронтенд, айос, андроид, qa) которые непрерывно работают на проекте и копают спринтами один за другим. И ни кто никого не гонит. Заказчик купается в бабле

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

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

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