?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Задачка-водокачка № 10
psilonsk
Десятая задачка-водокачка прилетела к нам из далеких краев, где в компаниях люди живут по правилам, непривычным для центра России.

Итак, вы – менеджер в одной производственной компании.


Это компания среднего размера, базирующаяся на достаточном удалении от крупных городов в небольшом городке Западной Сибири, с население меньше 100 тысяч. У компании есть представительство в довольно крупном и расположенном неподалеку городе А  – большая часть сотрудников работает вахтовым методом с перелетом именно из этого города. Что добавляет пикантности вашей ситуации – программисты тоже работают вахтовым методом (по 15 или 30 дней).

Для производственных нужд компании нужно разрабатывать программное обеспечение (ПО). В производстве используется большое число специфичного ПО и довольно большой зоопарк программных средств собственной разработки (от небольших программок до весьма сложных комплексов), но все они построены на устаревших и далеко не оптимальных технологиях.
Как это часто бывает, ни по одной из программ нет документации – системы «росли» а не проектировались и развивались, а их авторы в компании уже не работают.
Качество ПО достаточно низкое, многие программы в стадии «поддерживать не в состоянии – отказаться не можем». Постановка задач бизнесом на разработку и доработку также на крайне низком уровне – при разработке обязателен тесный контакт с ключевыми пользователями и экспертами предметных областей, чтобы выяснять детали. Для разработки ПО в этой отрасли нужны узкоспециализированные знания.

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

В разработке самого технически сложного проекта (и продукта) задействован специалист по имени дед Матвей. Это специалист высокого уровня, «носитель знаний». Он и правда приближается к дедовскому возрасту – ему более 50 лет.  Дед Матвей тоже работает «по вахте», летает не из города А (вообще, разработчики из разных городов). Дед Матвей плохо работает в команде, он совсем не командный игрок и крайне негативно относится к «модным» удаленным способам общения и работы (системы баг-трекинга, контроля версий кода и т. п., skype и прочее). Он не совсем программист даже – по образованию инженер-электронщик, но когда-то руководил разработкой такого же по функциональности комплекса. С технической точки зрения дед Матвей почти незаменим, но работать с ним крайне тяжело из-за вышеописанных особенностей. Деду Матвею поручили и менеджерскую работу на проекте, но он к ней не способен. Отдать этот проект никому нельзя и из-за технических особенностей – тестировать его можно только с подключенными приборами, которые физически находятся на производственной базе предприятия.

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

Собственно, вопросы задачки:
1.    Как правильно организовать эффективную разработку ПО на таком предприятии?
2.    Как можно привлечь туда специалистов?
3.    Как правильно работать с дедом Матвеем?

Подойдите к этой задачке не как к вопросу "как бы нам переделать Россию?" (увы, не переделать), а с грамотными управленческими рекомендациями.


Поскольку ответов к этому кейсу пока нет, по нашей традиции комментарии открыты (примерно до пятницы).



promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
ох, по моему это идеальная работа :))) сижу читаю и руки чешутся ) как хочется быть везде и сразу ) столько хороших мест пропадает )))

Так поезжайте. )

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

2. 3. - не важно как, они в максимизации прибыли от проекта роли не играют

"философски настроенные жители сыктывкара нашли позитивное начало в проживании в сыктывкаре"

Классическая ситуация роста.

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

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

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

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

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

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

Пошаговая, сработавшая в подобной ситуации в реальности, схема:
1. К неконтактному пенсионеру - носителю знаний цепляется молодой специалист, основной задачей которого выступает формализация знаний. Специалист должен соответствовать трем требованиям: возраст от 22 до 25 лет, сумеет найти общий язык с пенсионером, сумеет задокументировать полученные тайные знания. Работа остальной команды должна быть организована так, чтобы общение с "дедом Матвеем" сводилось к набору вопросов, ответы на которые затем также должны быть документированы.
2. Формализовать постановку задача. Так как бороться со сложившейся системой постановки задач и запуска проектов тяжело, нужно построить процесс постановки задачи так, чтобы неопределенность завершалась на менеджере. Как менеджер этого добьется - вопрос к конкретной ситуации, есть ли возможность договориться с директором и замом, или нужно манипулировать :)
3. Процесс работы "вахтовых" команд нужно организовать так, чтобы за "вахту" они успевали завершить и внедрить в работу кусок функционала, поправить все критичные баги и к следующей вахте накопить сведения о использовании фукционала и необходимых изменениях.

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

Молодой специалист (а может даже парочка) тут прямо просится. Идеально - САПРовец по профилю компании, что бы и в предметной области разбирался и мог объяснить всё это неспециализированным программистам, в том числе удалённо. Он может выезжать на вахты вместе с дедом или вообще на некоторое время поселиться в этом небольшом городке. Остальная команда может располагаться где угодно.

Дед Матвей - интересная, но и самая простая часть проблемы.

Ну так и начинать надо с самого простого)) Такую работу - через небольшой отдел молодых специалистов - можно построить и с остальными ключевыми пользователями/постановщиками задач на разработку и доработку. Если подбирать не обременённую семьёй молодёжь, можно обойтись даже без вахтового метода, а на 1-2 года. Высокая з/п и приобретаемый опыт будут вполне хорошей мотивацией. А основное ядро профи-программистов расположить в А. Они вахтами могут приезжать на внедрение.

>Как правильно организовать эффективную разработку ПО на таком предприятии?
1. Деда ставим Архитектором и его надо на постоянку переводить либо в своем городе, лучше либо в городе А.
2. Команду аналитиков вахтовым методом оставлять на заводе с пользователями. Разработчиков рядом с аналитиками, т.к. возможно будет страдать формализация и актуализация требований к системе. Поставить Jira или нечто подобное.
3. Тим лидов либо на постоянку либо командировками отправляем к деду, т.к. для своих подчиненных они вполне донесут все удаленно и соберут вопросы для деда.

>Как можно привлечь туда специалистов?
Для аналитиков и программистов - а они основной ресурс, ограничений нет.
Выгодная вахта и хорошая зп эти условия достаточны для формирования команды.

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

UPD: при отправке поста случился какой-то сбой и коммент не появился. Это дубль.
ДедМатвеи -- частая ситуация на проекте, поэтому это не проблема, а вопрос правильного использования специалиста.
Если абстрагироваться от ситуации в IT на данной конторе вообще, то я вижу, что тут не хватает 2-х серьезных ролей:
1. Постановщика задач (аналитика). Из-за этого решения плохо задокументированы.
Плюс в постановщике в том, что хорошо написанную постановку понимает не только мега-крутой спец, но и смежные специалисты. Есть возможность усовершенствовать (упростить) реализацию за счет оптимизации. К тому же с течением времени важные знания не пропадают и следующему программеру не придется ковырять чужой код (хорошо закомментированный код все равно уступает задокументированному).
Аналитик не при каких обстоятельствах не должен быть программером -- только техспецом с профильным образованием. Ну или просто с большим опытом документирования в любой отрасли. Тут еще много можно писать почему прогеры -- плохие постановщики. А тем паче -- для самих себя.
2. Системного аналитика (архитектора системы). Без системного аналитика из решения, которое делают 5-10 прогеров получается плохосовместимый зоопарк. Да и вообще нужен человек, который ставит точку в технических вопросах и имеет представление о том, как работают и взаимодействуют все части системы.
Вообще, этапом анализа при разработке здесь явно пренебрегают, а без него очень тяжело двигаться дальше.

Это диагноз. Теперь лечение:
1. Нанять аналитиков (постановщиков). Много не потребуется. очень желательно со спецобразованием. Документировать весь процесс постановки задач, интервьюирования, описать и согласовать все причастные техпроцессы и бизнес-процессы.
2. Я не знаю как привлечь быстро туда специалистов. Могу только предположить, что если процесс постановки задач будет хорошо отлажен и будет нормальный архитектор проекта, что чать работы может выполняться удаленно. За двойную ЗП сидеть дома много желающих найдётся.
3. ДедМатвея назначить Самым Главным Консультантом проекта. И чтоб он обязательно согласовывал все техдокументации и постановки. Тогда скайпа, багтрекера и прочего ему и не понадобиться

  • 1