Pull to refresh

Ролевые игры

Reading time 4 min
Views 2K

Тринадцатый выпуск нашего подкаста “В бесконечность и далее” мы назвали “Ролевые игры”, потому что в нём (начиная с 14й минуты) мы моделируем жизнь и действия менеджера, на которого неожиданно свалился IT проект по заказной разработке ПО, а сам менеджер и его команда к этому проекту не готовы. Ситуацию усугубляет то, что


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

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


Описание ситуация: есть большая компания-заказчик численностью 5 000 сотрудников интеллектуального и полуинтеллектуального труда. В настоящий момент компания-заказчик находится на стадии лоскутной автоматизации, т.е. у неё есть много старых информационных систем, которые автоматизируют бизнес процессы по принципу “так исторически сложилось”. Заказчик наняла две конкурирующие IT компании переписать весь этот зоопарк имеющееся IT наследие на современных технологиях. Сферы ответственности между подрядчиками изначально жестко разделены Заказчиком, но если кто-то из Подрядчиков не будет справляться — Заказчик может перераспределить и деньги, и работы, и, даже, привлечь новых Подрядчиков.



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


  1. Первый шаг — это попаниковать первые 5-7 минут, а потом начать методично работать
  2. Мы задаемся риторическим вопросом “Как нет команды? Какой же ты менеджер, если у тебя всего 2 человека”, но приходим к выводу, что людей-то может быть хоть 100, но в любой нормальной компании эти люди чем-то постоянно заняты и у них может и не быть времени на новый проект
  3. Констатируем очевидное — чем больше больше команда , тем проще высвободить ресурсы на неожиданные проекты/задачи
  4. По сути, надо сделать три вещи:
    • нарастить команду
    • не потерять клиента и не дать умереть своей компании, пока мы работаем над проектом (последнее касается небольших компаний: кончились деньги и оплата от заказчика еще не пришла — добро пожаловать, Банкротство)
    • не проиграть конкуренту (выигрывать не обязательно, а вот проиграть — нельзя)
  5. Мы вводим важные уточнения:
    • компания-конкурент сильнее нашей компании вовсе не потому что родственник их владельца работает у заказчика (или из-за какой-нибудь политики), а просто они лучше разбираются в теме
    • мы работаем по контракту длинной 3 года, т.е. есть время “разбежаться”
  6. Надо помнить, что один проект должен и обязан перетечь в другой проект, потому что если нет — не понятно что делать с командой старого проекта. Увольнять глупо — и с людьми расставаться сложно, и новых не наберешь, и моральный климат в компании пострадает, а с другой стороны — зарплаты платить им не с чего
  7. Три фронта работы менеджера:
    • Заказчик — выстроить с ним хорошие отношения
    • Компания-конкурент — нужно либо вступить в коллаборацию, либо в конфронтацию, но всегда держать их “на виду”
    • Своя команда. Это самая важная часть. Но все три необходимые и каждая по отдельности не достаточны
  8. Нужно запустить найм людей как можно раньше. Рынок “труда” сейчас тяжелый и трудный, но с другой стороны, анализируя рынок ты не обязан никого набирать прям сразу. Ты можешь составить базу резюме и есть вероятность что к моменту когда будет нужен реальный найм, многие люди из списка еще не найдут работу
  9. Еще не плохо бы изучил HR политику компании, потому что там с большой вероятности всё плохо
  10. Описание вакансии надо написать самому или привлечь 2-3 аналитиков
  11. Нужно пытаться как можно больше процессов вывести на уровень “работает без тебя”, иначе кранты… иначе ты погрязнешь в микроменеджменте
  12. Придется управлять ожиданиями заказчика и писать планы. Даже не смотря на то что это профанация. Потому что будет разрыв между началом работы и первыми результатами и чем-то надо наполнить его, например, планом
  13. Если заказчик будет терять доверие – будем переписывать план
  14. С самого начала нужно сделать для заказчика единую точку входа в виде менеджера или аналитика, который будет в постоянно тесном контакте с заказчиком. Это удобно заказчику, это полезно вашей команде
  15. А еще можно устроить подобие “картельного сговора”, потому что если мы крупные IT подрядчики, то мы встречаемся ещё где-то помимо этого заказчика, а значит есть ли смысл ссориться из-за одного кусочка пирога, если пирог большой? Лучше сохранить хорошие отношения. Об этом можно послушать тут
  16. А вообще, хорошие отношения с людьми, которые занимаются такой-же работой как твоя это правильно и полезно в любом случае, потому что хорошие отношения всегда лучше плохих. Это работает и для компании заказчика, и для компании конкурента
  17. Задача менеджера, скорее, сохранить, нежели приумножить. Если дела обстоят наоборот — это уже не менеджер, а предприниматель
  18. Обязательно нужно написать “Устав проекта”, который должен быть написан таким языком, как если бы вы писали “правила общежития”. Т.е. просто и понятно. Нужен он для новых сотрудников и вообще, как общий ориентир. Потому что жить с этим документом лучше чем без него
  19. Надо помнить, что важно не только то что ты делаешь и насколько хорошо ты это делаешь, не менее важно как это видит руководство и смежники. Потому что если ты молодец, но об этом никто не знает, то ты не молодец
  20. Процесс разработки (т.е. фактически — самой работы) должен быть прозрачным, чтобы вы точно знали на какой стадии находится проект. Возможно, этот процесс следует сделать прозрачным даже для заказчика
  21. Так или иначе, кто-то должен задать первоначальный стандарт используемых технологий для отслеживания активности по проекту. Почему бы это не сделать менеджеру? Например доски типа Trello или что-то в Jira
  22. Обязательно нужна база знаний. Не обязательно Confluence, бесплатные варианты тоже подойдут
  23. Ну и конечно, нужен общий чат. Он нужен в любом случае. С другой стороны, чаты это зло так как они отвлекают. Поэтому нужно искать золотую середину в использовании этого чата, которая, кстати, для каждого своя
  24. Мы обсудили процесс до момента когда "пушки поставлены, снаряды подведены", а дальше надо работать и решать проблемы, которые неминуемо будут возникать
  25. А вообще, у нас есть план, который мы писали для заказчика в пункте 12, и первые вехи этого плана — это те самые первые задачи с которых и нужно начинать

Спасибо что дочитали! Если хотите что-то спросить или сказать — пишите нам в наш чат-флудилку или на почту!


Нажмите чтобы узнать где нас послушать
Tags:
Hubs:
+3
Comments 0
Comments Leave a comment

Articles