Outsourcing - negative experience
Apr. 26th, 2006 10:59 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
redisИтак, наш проект закрыт.
Попробую подытожить новый опыт, полученный на проекте и его закрытии.
Проект, в принципе, можно отнести к аутсорсингу, так как формально независимая латвийская фирма работала на немецкого заказчика, получая деньги за человеко-часы. Большой немецкий Проект был разбит на несколько проектов (около 20-ти), часть из которых было получено создавать и поддерживать нам. Суб-проекты небольшие, около десяти c-файлов килобайтов по 30-60 каждый. На мне, например, висело в среднем 4 таких проекта, плюс один независимый на Perlе. Есть пара примет, по которому я бы его к аутсорсингу не отнес - об этом ниже.
Основные проблемы и ошибки, приведшие в конце концов к закрытию проекта:
1. Нехватка информации у нас. Нам постоянно не хватало информации о том, что происходит с центральным проектом, какие приняты решения, какие будут происходить изменения, чем и зачем мы собственно заняты. У немцев каждый понедельник были митинги на которых решалось, что и как делать дальше и уточнялся статус Проекта и проектов. У нас не было об этом обсуждении никакой информации, что приводило к тому, что мы зачастую говорили с немцами на разных языках. Возможное, но так и не реализованное решение - конференц-call с нами по результатам еженедельного митинга в Берлине.
2. Нехватка информации у немцев. Основным источником информации для немцев служили наши ежедневные отчеты, которые каждый программист писал самостоятельно. Если у немцев возникали вопросы, они запрашивали дополнительную информацию. При этом возникали две проблемы: во-первых немцы, как уже сказано выше, исходили из того, что мы в курсе принимаемых решений и изменений, и задавали вопросы, ответить на которые точно мы не всегда имели возможность без получения дополнительной информации. Во-вторых, у нас был свободный график, что приводило к тому, что ответ мог задерживаться на пару дней. Возможное решение - team-leader в Латвии, являющийся промежуточным звеном между немцами и нами, способный ответить на немецкие вопросы о статусе проекта, см.ниже. Кроме того, один из наших сотрудников... но о нем речь тоже ниже.
3. Неправильная иерархическая структура. У немцев был один человек, project manager (PM), который отвечал за состояние Проекта и проектов. При этом он работал непосредственно с каждым немецким программистом (порядка 20 человек), плюс персонально с каждым латвийским (4-10 человек). Дополнительно, каждый латвийский программист работал также напрямую с немецкими коллегами и получал от них просьбы или указания, иногда противоречащие указаниям PMа. На вопросы немецкий PM иногда отвечал в течении нескольких дней. Когда Проект пошел в производство, немецкий PM полностью потерял контроль над латвийской стороной по причине банальной нехватки времени. При этом один из оставшихся на тот момент четырех наших программистов полностью сорвался с цепи и перестал работать вообще, лишь отсылая рапорты о проделанной работе, в которых откровенно врал. Я был первым, кто это обнаружил, однако мы были не способны принять соответствующие меры по причинам, изложенным в следующем пункте, и пришлось докладывать немцам. Не знаю, стоит ли называть этого программиста по имени, но его зовут Улдис Барбанс и он как раз сейчас ищет работу. Решение проблемы с иерархической структурой - ввести в Латвии своего team-leaderа, ответственного за латвийские проекты и непосредственно контактирующего с немецким PM, плюс решающего потенциальные конфликты между запросами немецкой стороны, находящегося в курсе немецкого Проекта и всех возможных требований.
4. Кадровый вопрос. Поскольку немецкий PM работал непосредственно и лично с каждым латвийским программистом, иногда специально ради этого летая в Ригу, он, естественно, хотел быть в курсе всех кадровых решений на латвийской стороне и хотел лично их одобрять. При этом, изначально коллектив латвийской стороны набирался на основе краткосрочных почасовых контрактов, а не на постоянную работу, что привело к появлению в коллективе большого числа людей, пришедших на короткое время и работающих не полный рабочий день. В то время, как они начали уходить, людей стали брать на постоянную основу, однако во-первых, немцы уже решили, что у нас жуткая текучка кадров, во-вторых, немецкий PM потерял желание утверждать у нас новых работников, в то же время сохраняя требование об этом. Это привело к сокращению числа программистов на нашей стороне с десяти до четырех, соответствующему сокращению количества проектов, доходов и, как следствие, невозможности набирать хороших программистов за хорошие деньги. Дополнительным фактором является то, что каждый программист проходил дорогостоящий и продолжительный training. В сложившейся ситуации мы не могли уволить откровенно плохого работника и взять на его место кого-то другого. Решение проблемы кадрового вопроса: независимая латвийская фирма обязана отстаивать свою независимость в кадровом вопросе, введение team-leaderа снижает завязку немцев на конкретных людей на нашей стороне, training можно было проводить своими силами в Латвии.
5. Качество работы. Не зная принимаемых в Берлине решений и не имея возможности на них повлиять, не получая информации о запланированных сроках, мы не могли четко распланировать свое время между проектами, не могли осуществлять переброску людей с одного проекта на другой, не могли контролировать своих сотрудников. В целом, все проекты выполнялись по времени более-менее согласно немецким планам, часть намного раньше, часть слегка позже. Однако, программист, который откровенно не тянул, безумно затягивал все проекты - но об этом мы не могли знать. Самым вопиющим случаем было, когда латвийский программист, занятый не полное время, независимо занимался проектом в течении нескольких месяцев, создавая отчеты и получая за это деньги, заявив за неделю до сдачи, что проект "был удален при переустановке Windows". Решение - латвийский team-leader сам получает информацию о необходимых проектах, сам принимает решения о распределении их между программистами и сам ответственнен за соблюдение сроков.
6. Другой аспект качества - качество кода. Несмотря на наличие у немцев правил написания кода, наши программисты писали кто во что горазд и контроль кода на латвийской стороне не осуществлялся вообще. При этом страдала не только читаемость, но и падала совместимость с другими проектами - например, один латвийский программист писал функции, возвращающие не код ошибки, принятый в Проекте, а требуемое значение или, в лучшем случае, код ошибки операционной системы. Иногда даже в смешанном виде. Учитывая, что этот программист из принципа не ставит пробелов, любит в C оператор goto и не пишет комментариев, исправление его кода занимает больше времени, чем написание нового. Проблема кадрового вопроса не позволяла избавиться от этого программиста. Мой код проверялся немцами лишь однажды - в самом начале моей работы, после чего я мог писать как хочу. Решение: латвийская сторона обязана самостоятельно обеспечить приведение кода в соответствие с требованиями заказчика, для чего требуется специально обученный человек (возможно, тот же team-leader).
Вроде бы все. Если еще что вспомню, сделаю Upd.
Попробую подытожить новый опыт, полученный на проекте и его закрытии.
Проект, в принципе, можно отнести к аутсорсингу, так как формально независимая латвийская фирма работала на немецкого заказчика, получая деньги за человеко-часы. Большой немецкий Проект был разбит на несколько проектов (около 20-ти), часть из которых было получено создавать и поддерживать нам. Суб-проекты небольшие, около десяти c-файлов килобайтов по 30-60 каждый. На мне, например, висело в среднем 4 таких проекта, плюс один независимый на Perlе. Есть пара примет, по которому я бы его к аутсорсингу не отнес - об этом ниже.
Основные проблемы и ошибки, приведшие в конце концов к закрытию проекта:
1. Нехватка информации у нас. Нам постоянно не хватало информации о том, что происходит с центральным проектом, какие приняты решения, какие будут происходить изменения, чем и зачем мы собственно заняты. У немцев каждый понедельник были митинги на которых решалось, что и как делать дальше и уточнялся статус Проекта и проектов. У нас не было об этом обсуждении никакой информации, что приводило к тому, что мы зачастую говорили с немцами на разных языках. Возможное, но так и не реализованное решение - конференц-call с нами по результатам еженедельного митинга в Берлине.
2. Нехватка информации у немцев. Основным источником информации для немцев служили наши ежедневные отчеты, которые каждый программист писал самостоятельно. Если у немцев возникали вопросы, они запрашивали дополнительную информацию. При этом возникали две проблемы: во-первых немцы, как уже сказано выше, исходили из того, что мы в курсе принимаемых решений и изменений, и задавали вопросы, ответить на которые точно мы не всегда имели возможность без получения дополнительной информации. Во-вторых, у нас был свободный график, что приводило к тому, что ответ мог задерживаться на пару дней. Возможное решение - team-leader в Латвии, являющийся промежуточным звеном между немцами и нами, способный ответить на немецкие вопросы о статусе проекта, см.ниже. Кроме того, один из наших сотрудников... но о нем речь тоже ниже.
3. Неправильная иерархическая структура. У немцев был один человек, project manager (PM), который отвечал за состояние Проекта и проектов. При этом он работал непосредственно с каждым немецким программистом (порядка 20 человек), плюс персонально с каждым латвийским (4-10 человек). Дополнительно, каждый латвийский программист работал также напрямую с немецкими коллегами и получал от них просьбы или указания, иногда противоречащие указаниям PMа. На вопросы немецкий PM иногда отвечал в течении нескольких дней. Когда Проект пошел в производство, немецкий PM полностью потерял контроль над латвийской стороной по причине банальной нехватки времени. При этом один из оставшихся на тот момент четырех наших программистов полностью сорвался с цепи и перестал работать вообще, лишь отсылая рапорты о проделанной работе, в которых откровенно врал. Я был первым, кто это обнаружил, однако мы были не способны принять соответствующие меры по причинам, изложенным в следующем пункте, и пришлось докладывать немцам. Не знаю, стоит ли называть этого программиста по имени, но его зовут Улдис Барбанс и он как раз сейчас ищет работу. Решение проблемы с иерархической структурой - ввести в Латвии своего team-leaderа, ответственного за латвийские проекты и непосредственно контактирующего с немецким PM, плюс решающего потенциальные конфликты между запросами немецкой стороны, находящегося в курсе немецкого Проекта и всех возможных требований.
4. Кадровый вопрос. Поскольку немецкий PM работал непосредственно и лично с каждым латвийским программистом, иногда специально ради этого летая в Ригу, он, естественно, хотел быть в курсе всех кадровых решений на латвийской стороне и хотел лично их одобрять. При этом, изначально коллектив латвийской стороны набирался на основе краткосрочных почасовых контрактов, а не на постоянную работу, что привело к появлению в коллективе большого числа людей, пришедших на короткое время и работающих не полный рабочий день. В то время, как они начали уходить, людей стали брать на постоянную основу, однако во-первых, немцы уже решили, что у нас жуткая текучка кадров, во-вторых, немецкий PM потерял желание утверждать у нас новых работников, в то же время сохраняя требование об этом. Это привело к сокращению числа программистов на нашей стороне с десяти до четырех, соответствующему сокращению количества проектов, доходов и, как следствие, невозможности набирать хороших программистов за хорошие деньги. Дополнительным фактором является то, что каждый программист проходил дорогостоящий и продолжительный training. В сложившейся ситуации мы не могли уволить откровенно плохого работника и взять на его место кого-то другого. Решение проблемы кадрового вопроса: независимая латвийская фирма обязана отстаивать свою независимость в кадровом вопросе, введение team-leaderа снижает завязку немцев на конкретных людей на нашей стороне, training можно было проводить своими силами в Латвии.
5. Качество работы. Не зная принимаемых в Берлине решений и не имея возможности на них повлиять, не получая информации о запланированных сроках, мы не могли четко распланировать свое время между проектами, не могли осуществлять переброску людей с одного проекта на другой, не могли контролировать своих сотрудников. В целом, все проекты выполнялись по времени более-менее согласно немецким планам, часть намного раньше, часть слегка позже. Однако, программист, который откровенно не тянул, безумно затягивал все проекты - но об этом мы не могли знать. Самым вопиющим случаем было, когда латвийский программист, занятый не полное время, независимо занимался проектом в течении нескольких месяцев, создавая отчеты и получая за это деньги, заявив за неделю до сдачи, что проект "был удален при переустановке Windows". Решение - латвийский team-leader сам получает информацию о необходимых проектах, сам принимает решения о распределении их между программистами и сам ответственнен за соблюдение сроков.
6. Другой аспект качества - качество кода. Несмотря на наличие у немцев правил написания кода, наши программисты писали кто во что горазд и контроль кода на латвийской стороне не осуществлялся вообще. При этом страдала не только читаемость, но и падала совместимость с другими проектами - например, один латвийский программист писал функции, возвращающие не код ошибки, принятый в Проекте, а требуемое значение или, в лучшем случае, код ошибки операционной системы. Иногда даже в смешанном виде. Учитывая, что этот программист из принципа не ставит пробелов, любит в C оператор goto и не пишет комментариев, исправление его кода занимает больше времени, чем написание нового. Проблема кадрового вопроса не позволяла избавиться от этого программиста. Мой код проверялся немцами лишь однажды - в самом начале моей работы, после чего я мог писать как хочу. Решение: латвийская сторона обязана самостоятельно обеспечить приведение кода в соответствие с требованиями заказчика, для чего требуется специально обученный человек (возможно, тот же team-leader).
Вроде бы все. Если еще что вспомню, сделаю Upd.
