Менеджер чрезмерно упрощает проектные задачи и сроки

Я работаю руководителем оффшорной разработки ERP в компании BPO, и у меня есть оншорный менеджер ("MM"). Помимо того, что я разработчик, я также выполняю много работы по поддержке и тестированию, так как у нас немного не хватает рук.

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

ММ: «Итак, каковы ваши текущие задачи прямо сейчас?»

Я: «В настоящее время я заканчиваю разработку Project X и должен закончить тесты в течение двух дней».

ММ: «Два дня? Почему это заняло бы так много времени? Разве это не должна быть просто строка кода, которую вы должны изменить и быстро протестировать?»

Я: «Это немного сложнее. Мне нужно изучить сценарии и провести регрессионное тестирование, чтобы убедиться, что это не повлияет на другие нижестоящие системы».

ММ: «Нет, вы чрезмерно анализируете вещи, это простое решение, и оно не должно нуждаться в регрессионном тестировании».

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

Кажется, это была культура компании, в которой они не придерживаются ИТ-стандартов и политик ( Мой менеджер нарушает ИТ-политики и не придерживается стандартных практик ).

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

ЕСТЬ ли в вашей компании стандарты (в смысле конкретного документа или процесса, на который вы можете ссылаться)? Кто отвечает за качество продукта? Кому принадлежат стандарты и сроки?
разве программирование не просто печатание на клавиатуре? </сарказм>
Кстати, «ММ» в этой серии вопросов — не я. :)
@dwizum, с тех пор, как я сюда попал, мне не было представлено ни одного документа о наших стандартах кодирования и сроках. На самом деле я пытался представить его в течение первых нескольких месяцев, но он был (косвенно) отклонен.
«Двигайся быстро и ломай вещи» сделало парочку миллиардеров здесь и там. «SuperCell» удается иметь массовые очевидные ошибки клиента в каждом обновлении и по-прежнему зарабатывать миллиарды долларов наличными. Там, где задействованы такие аббревиатуры, как «ERP» и «BPO», может потребоваться более строгий процесс, но с каждым годом вам будет все труднее найти коллег, которые согласны, что вы должны вносить аванс, чтобы гарантировать, что ничего не сломается в процессе производства, и это это смущение/неудача, когда это происходит.
Решения ERP, а именно от немецкой компании в этой области, печально известны в этих краях тем, что каждое изменение ломает всю систему в огромных масштабах (генеральные директора были уволены, компании потеряли 10% доли рынка, 3 месяца потерянных продаж, и т. д). Таким образом, ERP не означает автоматически более тщательное тестирование;)
Вы находитесь в офшоре, и ваш менеджер на месте просто хочет сделать все как можно быстрее и не заботится о качестве кода после того, как услышит, что это займет больше времени, честно говоря, я в шоке.
Каждый отдельный проект, когда-либо сделанный для каждого отдельного программного продукта, каждый сделанный - идет именно так.

Ответы (2)

Это что-то, что я должен обострить?

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

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

Я думаю, что вам лучше всего в следующий раз, когда что-то сломается в продакшене , где это применимо, объяснить/продемонстрировать, как правильный план тестирования мог бы спасти ситуацию .

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

Будьте бдительны в своих оценках и тестировании!

Чем дольше вы работаете над частью программного обеспечения, тем лучше будут ваши оценки. Вы лучше своего начальника знаете, сколько времени требуется для реализации функций и устранения проблем, поэтому продолжайте оценивать, насколько вам известно. Я тоже вношу изменения в код, которые должен протестировать лично, и поэтому мне нравится умножать время на исправление/внедрение в 1,5 или 2 раза в зависимости от проблемы или функции. К счастью, мой босс понимает это, потому что он был разработчиком программного обеспечения.

Каковы последствия ненадежного тестирования вашего программного обеспечения перед его фиксацией? Технический долг . Мы, разработчики (должны) это знать!

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

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

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