Я программист в душе. Первую программу написал в 8 лет — игра на ламповый телевизор (24 года назад). Данный проект — это вызов для меня. Я лично не написал ни одной строчки кода. В процессе перекупили основного кодера. Дочь глотнула батарейку — стресс на неделю. Коронавирус. И факапы на старте, которые привели к доп расходам на 25% бюджета. Команда 7 человек и я. Сроки реализации 4 месяца.
Основные идеи в которых утвердился
- Если у Вас процесс занимает больше пару часов в день — скорее всего у вас все работает неправильно и много процессов завязано на Вас лично..
- Надо делать все, чтобы команда была самоорганизована. PM должен только организовывать процесс и только присматривать за процессами.
- PM + Product это одна профессия, по другому получится говняный результат! (взято из биографии Джобса). Дизайн и UX наше все! И не важно какой крутой вы процесс организуете, если заказчику не понравится!!! Важно подобрать талантливого дизайнера в проект.
- Со старта организовывать ОТК — в моем случае это доверенный тестировщик (подчеркиваю доверенный — исключаю сговоры), который попутно осуществляет контроль за процессами
- Важно соблюдать пошаговость процессов — это позволит сильно сократить бюджет. Не все люди нужны на фулл тайм со старта.
- Упрощай. Непрерывное совершенствование кайдзен. В моем случае периодический вопрос — как можно улучшить, ускорить? Что я делаю не так? Что можем упростить? итп
- Не бойтесь менять процесс если видите что, что-то идет не так и тормозит работу.
- Командообразование, но очень важный момент — в команде должны быть тщательно подобраны люди. Все помним про ложку дегтя. (когда-то такая ошибка мне стоила 100 тыс уе и год жизни).
- Диалог. Коронавирус и зум дал понимание — важно слушать о чем идут диалоги в команде. В моем случае, мне удается вовремя скорректировать важные ошибки. Очень часто в таком подслушивании выясняется, что задача данная Вами — искажена или не понята!
- Скрам не работает для мелких бюджетов. Аджайл хорошо, но последнее слово за PM. Важно влюбиться в проект (или не браться за него) и быть его Product менеджером
- Ваши проблемы — это лично Ваши проблемы. Заказчик о них не должен знать. Он также не должен знать Вашего плохого настроения. В то же время — вы должны быть на 100% вовлечены в его проблемы. Строим отношения — клиент оценит.
Мои факапы и выводы по проекту
- У PM однозначно должен быть планшет и пенсил чтоб рисовать то, что ты хочешь от людей. Слова часто не так трактуются.
- Нужно очень серьезно подходить к подбору людей, лично проводить контрольное собеседование и очень внимательно слушать о чем они говорят. В моем случае — я начал вести досье на сотрудников.
- Надо понимать кто и ради чего работает. И надо стараться знать о личной жизни людей в команде. Следить за настроением людей на планерках и узнавать что у них там не так. Строим отношения.
- Если перекупили — отпускай с улыбкой и обнимашками (потом это позволит консультироваться по написанному им коду). Спроси почему, дабы искоренить ошибку. Ну и перед уходом накидай ему все баги какие есть — опыт показал что они фиксятся в 3 раза быстрее чем обычно.
- СПРАШИВАЙ У СОТРУДНИКОВ. Как это делается? Как надо? Как думаете? Как лучше? — Вы генерал — они на передовой, им виднее!
- Важно либо лично знать как и что делается либо иметь супер оптимистичного доверенного тех лида. В моем случае я очень часто переубеждал людей что у них получится, что это не сложно и резал сроки в 2-3 раза. Ну и понимать что сотрудник несет какую-то херную — очень ценно!!!
- Не соглашаться с не получилось. Иди и делай дальше — я в тебя верю. Сработало раз 50. Взято из биографии Форда
- Хвали при всех. Закрывай рот и делай замечание при всех (это твой авторитет в стае)! Выноси мозг — one to one.
- Получилось случайно и сработало. На старте рабочий день 7- часов в день — креативность. Во время закрытия проекта — 8+ часов когда идет фикс багов и канбан. (идея взята из гарвардской статьи General Electric)
- Скрам по фичам а не по срокам. В моем случае сработало. Скрам по классике давал 2 недели кодинга и неделю фикса багов (в счет нового скопа работ). Полное непонимание людей что делать. После перехода на скрам по фичам — все пошло в 2 раза быстрее чем было без скрама.
- Не бойся позвонить клиенту и сказать, что просрал сроки. Главное сделать это заранее.
- Пошаговость реализации проекта — позволяет очень сильно сэкономить бюджет.
- Лучше сильно мудохаться над UX чем потом переделывать все с командой
- Поверь в проект сам. Влюбись в него сам (даже через не хочу). Просто прими, что это работа всей твоей жизни. Только после этого включаются остальные. Работает это и наоборот.
- Следите за слабыми звеньями — сильные хотят работать только с сильными (С. Джобс)
- СВОИ СОМНЕНИЯ НУЖНО ДЕРЖАТЬ ПРИ СЕБЕ. Может показаться, что ничего особенного не сказал, а люди уже пошли работу искать. В моем случае я заикнулся о том что не вижу перспектив в angular из-за его сложности. Чужие сомнения — жестко пресекать и при всех
- Онлайн команда дала мне +2 часа в день и очень сильно улучшило рабочий процесс (опять же правильный подбор людей по ценностям)
- САМООРГАНИЗАЦИЯ — надо максимально стремиться к тому, чтобы люди контактировали друг с другом и сами предлагали что им сделать. В моем случае — утренняя планерка и тупейший вопрос, который по началу ставил людей в ступор. Что сделал вчера? Что будешь делать сегодня? Возможно есть какие-то сложности.
- Правильный ОТК = ваша свобода и куча времени для проекта
- Общение в Zoom — позволяет оглашать всем все моменты по проекту. Часто те, кого это не касалось сильно поправляли других.
- Команда станет командой, если решит нерешаемый баг совместным консилиумом. В моем случае была поставлена задача — не уходить пока не решим проблему, ибо нам надо показать клиенту чтобы нам дальше платили зп (тут схитрил). Важно дать понять людям, что зп платит не фирма, а клиент!!!!
- Устранить муд из процессов. Думать об этом надо самому и постоянно спрашивать как можно сделать лучше. (книга Гемба Кайдзен)
- Любая проблема дана нам для того, чтобы мы ее решили и заработали на ней деньги (С. Тигипко — книга группа Приват). В моем случае, только когда я оказался в рамках ограниченного бюджета, серьезно начал относиться к оптимизации и пошаговости процессов. Заказчик оценил.
- Дал обещание — отвечай за свои слова. Лучше не обещать! Это Ваш авторитет в команде. ДЕЛЕГИРОВАТЬ!!! (книга 5-ти минутный менеджер)
- Всегда говори о людях позитивно. Всегда даже если они факапят — говори другим что у них все получится и будет все ок. За спиной не говорим ничего плохого — только в лоб!
- Гасить ссоры между людьми в зародыше и жестко! Часто они вызваны мелочами и желанием утвердиться. Объясняйте что мы вместе трудимся над одной целью
- Лично проводить опрос 360 и спрашивать все ли нормально в команде и проекте.
- Простой вопрос по утрам. Как можем улучшить? — творит чудеса. В моем случае сработало раза с 20. Тут важно терпение. (философия Кайдзен)
- Не тратим время на лишнюю документацию. Но пишем комментарии в коде инструкции по установке и настройке, чтобы другие кодеры нас не материли. Думаем о том, что клиент может кому-то показать код … (философия Agile)
- Не пускаем команду дальше, пока текущий скоп не начнет работать без багов. Будут протестовать — они хотят творить. Но практика показала, что это правильное решение.
- Обязательно проводить тестирование по чек-листам и обязательно перед релизами тестить еще раз.
- Не чаще чем 1-2 раза в 3 часа спрашивать, что от тебя надо и чем можешь помочь. Не мешаем им работать. Оказалось самым сложным.
- Нужно сохранять свои наработки — для копипаста. Это позволит очень сильно сэкономить бюджет и заработать в будущем. В моем случае код чата, тех. поддержки, работа с картой итп.
- Смена ЗП — говорим, что хотим это сделать и предлагаем это сделать на следующем проекте. Сработало.
- ТАЛАНТЛИВЫЙ МИДЛ — 2 мидла лучше сеньора или мидла и 2х джунов
- НЕЛЬЗЯ БЫТЬ ПЕРЕДАСТОМ — заставляйте людей общаться напрямую, но либо слушайте о чем говорят, либо потом спрашивайте у обоих. Наша задача корректировать именно рабочие процессы, а не мешать работать. В моем случае вышло так, что команда не заметила как я переехал на море. Есть я в онлайне или меня нет в какой-то момент сало не супер важно.
- Надо вести досье на сотрудников от самого собеседования. Даже тех кого не взяли в проект или на работу. В моем случае мелкий проект был отдан собеседованному сотруднику, как фрилансеру. Клиент доволен.
Для работы мной стало использоваться Trello. Универсальное и очень удобное. Туда добавили 4 плагина и немного изменили логику работы по канбану. Всем спасибо и хорошего кода.
Mindgrow
Вы пишете, что не нужно писать документацию, достаточно комментариев в коде.
А представьте, что у вас проект, которому 10 лет, в котором куча интеграций и реализованных процессов, и люди, которые начинали разрабатывать этот проект — уже не работают в нём. И вот вы приходите на такой проект как PM, и команда у вас новая.
Что будете делать, когда разрабы начнут задавать вопросы по интеграции со смежными системами? В комментариях вы sequence диаграмму не построите, а для самостоятельного разбора разработчиком — может понадобится дополнительное время, которого можно было бы не тратить, в случае если существовала документация.
Документацию писать не надо, а в коде такое не опишешь, таким образом, на деле информации нигде не останется и каждому разрабу придётся тартить время на анализ. На сколько это рационально?
Или другая ситуация — возникает вопрос по бизнес фиче, реализованной неизвестно когда, например — «Что такое Специальный счёт и в каких случаях его можно использовать». На уровне программиста в этом не так просто разобраться, так как ваша система может включать в себя часть бизнес-логики других систем, и чтобы разобраться в этом, нужно проделать достаточно большую коммуникацию.
К этим ситуациям еще интересно как вы будете себя вести в случае других вопросов по бизнес-процессам, реализованным в системе. Люди меняются, документации не остаётся, в комментах БП не описать. Что делать?
Dekmabot
На мой взгляд, в документации описывается "стратегия", а в комментариях — "тактика".
Общей картины не понять по комментариях, и они выносятся в доки. И наоборот, если в доке описывать мелкие детали — документация устаревает в момент.
Если компания не ведёт документацию — у неё просто нет технической стратегии. Для стартапа это простительно, для серьёзных вещей — нет.
Mindgrow
В документации описывается факт, а стратегия и тактика имеет отношение к плану.
Без документации по хорошему можно обойтись на этапе MVP так как бизнес-требования формируются. Но когда продукт масштабируется, обрастает функционалом и у него появляется большое количество пользователей, то банально без пользовательской документации будет больно.
Заказчик может и будет рад увидеть красивый интерфейс, и подтвердит выполнение. Но массово продавать и внедрять этот продукт без банальной пользовательской документации будет больно. А у многих сегодняшних систем нет банальной пользовательской документации. Как правило такие продукты не отличаются качеством…
Dekmabot
Видимо моя аналогия не понятна, прошу прощения, поясню:
Под "Стратегия" и "Тактика" имел в виду принципиальные вещи и конкретную реализацию, то есть углублённость документации в детали.
К примеру "Платёжное апи содержит следующие методы" — это одно. А "Кнопка имеет зелёный цвет и при наведении окрашивается в красный" — другое. Документация должна давать представление, а "куда чего передаётся" и другие часто меняющиеся вещи там могут отсутствовать.
Mindgrow
Странная у вас аналогия.
Есть пользовательская документация, есть техническая документация. Их много видов. Я выше привёл ситуации в которых мне интересно как бы поступил ПМ при отсутствии той или другой.
Описать API в коде может быть сложнее чем в отдельном word документе. Допустим используется SOAP API с автогенерацией кода…
Alekseyz
А если клиент не готов платить за документацию? Надо же как-то и кому-то обьяснить клиенту важность ведения документации и обосновать такую разницу в стоимости.
Mindgrow
У нас тема про процессы разработки, а не про продажи.
Для того чтобы объяснить клиенту разницу в стоимости надо развивать навыки продаж.
Опять же, если клиенту нужен MVP, собранный на коленке — отсутствие документации не такой ужасный фактор. Но если идёт речь о массовом продукте с тысячами пользователей планируемом на долгосрок, то отсутствие документации это боль. Обосновать тут можно хотя бы количеством запросов новых пользователей, у которых будут возникать вопросы по продукту — всё это вопросы в тех поддержку либо недополученная прибыль из-за того, что пользователь просто забил не разобравшись. Потом если система корпоративная и это крупная компания — то ИТ не примет продукт без документации и ваш клиент не сможет продать вами разработанный продукт, если вы делаете ПО на заказ.
Alekseyz
Никто не спорит что документация это плохо, но на нее часто забивают так как сложно продать, тем более на этапе сопровождения.
Mindgrow
Повнимательнее прочитайте что я написал.
У меня есть петпроджект на гитхабе. Доку я не пишу, но когда дойду до масштабирования, она будет как июминимум чтоб у потенциальных пользователей-клиентов что то было на руках.
Если вы лендинг за 30к делаете, то тоже можно без документации обойтись.
Не торопитесь с ответом. Обдумайте
Mindgrow
И ещё вариант обоснования — посчитать
— на сколько уменьшится время интеграции нового разраба в проект, за счёт того, что он сможет самостоятельно освоить систему
— сколько будет сэкономлено времени на обращение и отвлекание коллег
— сколько будет времени сэкономлено на уменьшении времени на анализ и вспоминание того как что должно работать
Все эти моменты выливаются в трудочасы, сдвигание сроков, что в конечном итоге выливается в деньги для клиента и может выйти не мало.
Это если проект крупный. Если проект мелкий, то можно и забить
uisgroup Автор
Добрый день. Спасибо за комментарий. Имел ввиду, что лучше вначале написать код, а потом под него документацию. Если говорим о том, что надо экономить бюджет