Как донести до начальника серьезность проблемы?

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

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

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

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

Желаемые результаты включают, но не ограничиваются

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

2) найти новое, отличное решение для нашего клиента, отказавшись от купленного шаблона

Обратите внимание, я работаю удаленно.

тебе понадобилось шесть месяцев, чтобы понять, что ты не можешь делать это должным образом?
@Kilisi Шесть месяцев были у моего коллеги, который почти не работал над проектом в то время, и его действительно не заботило, сработает ли что-то в конце концов.

Ответы (4)

Составьте список с денежными значениями.

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

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

Затем добавьте свои догадки (пожалуйста, не дикие) и дайте примерную цифру их влияния.

Потом напишите все это своему начальнику и менеджеру.

Если вы доберетесь туда, ваша работа будет выполнена: принимать бизнес-решения не ваша роль, но вы должны предоставить фактические данные заинтересованным сторонам.

Возможно, вы захотите обновить свое резюме, если фотография или результат будут действительно неприятными.

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

Поставьте себя на место клиента и представьте риски для компании:

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

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

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

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

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

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

2) найти новое, отличное решение для нашего клиента, отказавшись от купленного шаблона

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

По моему опыту работы в ИТ-индустрии, участие в управлении рисками было низким, но это был один из самых эффективных способов показать, что что-то не работает. Я читал кое-что, в котором обсуждалось эффективное управление рисками, которое можно было бы применить к вашей проблеме;

  • Интегрируйте управление рисками в процесс принятия решений
  • Создайте сильную культуру управления рисками
  • Раскрытие информации о рисках/потенциальных рисках
  • Постоянное улучшение

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

Так что фраза «это $#@%, и мы не можем продолжать это делать» — это не то, что он хочет услышать, он просто будет продолжать доить проект, пока может. Это бизнес для вас.

Но говоря: «Это ^%$#@, нам нужно… наметить шаги и стратегию решения… и это будет стоить… сроки… и т. д.». Дает ему что-то, во что можно инвестировать.