Як врятувати молодий і вмираючий проект?

Я публікую це анонімно, тому що я не хочу потрапляти в потенційні проблеми.
У мене велика проблема.
Нещодавно я приєднався до команди, якій менше року. Я тут вже з місяця, щоб розпочати проект. Структура компанії виглядає так:

• Власник (нетехнічний)
  • Керівник проекту (нетехнічний)
    • Провідний розробник (технічний, але поганий у цьому)

Цей проект - це веб-сайт, що використовує ASP.Net, для якого провідний розробник створив жахливу архітектуру. Вам доведеться взяти моє слово на це, але в основному спосіб, який ми вимагаємо для створення веб-сторінок, дає нам 3+ хвилин завантаження на одній веб-сторінці через VPN в режимі налагодження.

Це спіраль до того, що інші співробітники погоджуються, що вони витрачають більше дня на очікування завантаження сторінок, ніж на фактичну розробку.

Зараз велика проблема в цьому. Керівник проекту не знає технології і визнає це. Він спеціально заявив, що довіряє Провідному розробнику робити правильний вибір архітектури додатків.

Ніхто з команди не знає, якою була б думка власників, але всі бояться заробляти хвилі в цій економіці (особливо я).

Що б ти зробив?

Цю проблему можна продемонструвати керівнику проекту в дуже нетехнічних умовах. Поставте свій сайт у вікно браузера перед прем’єр-міністром і попросіть його пограти з ним деякий час. Приблизно через два завантаження сторінки, головного розробника слід викликати на килим, якщо все так само погано, як ви кажете.

Прем'єр-міністр може не мати спеціальних знань з розробки, щоб зрозуміти, чому це погано, але він може бачити для себе як загального користувача веб-сайту, що це так. Інші сайти, що демонструють подібне завантаження інформації, за частку вашого часу, і ваш завантажується через локальну мережу з сервера в сусідній кімнаті.

Якщо це не летить, то йдіть до власника. Власник - гроші з грошима, але він дуже швидко зможе побачити той повільний веб-сайт, який ніхто не відвідуватиме == грошей немає. Налаштуйте ту саму демонстрацію, і перед завантаженням першої сторінки він повинен дзвонити ПІД ЧАСУ та ведучого на свій значно плюшевий килим.

Якщо ви переживаєте за те, щоб один хлопець робив хвилі, знайдіть більше одного розробника, готового висловити свої занепокоєння. Чесно кажучи, у такій компанії, як ваша, якщо продукт, який ви розробляєте, - це бомба, ви не працюєте, чи говорите ви, чи мовчите. Тож дивлячись на це таким чином, вам нічого не втрачається, крім пари додаткових тижнів чи місяців з компанією. Якщо це проблема, заплануйте деякі "прийоми у стоматолога" і шукайте нову роботу, перш ніж висловлювати свої проблеми, тож якщо ви втратите цю роботу, почніть наступний понеділок.

Якщо припустити, що ваші твердження точні, у вас є некомпетентний провідний розробник та некомпетентний керівник проекту (принаймні, настільки, наскільки він не може оцінити навички команди). Чудово. Ви маєте такі самі варіанти, як розробники для кожної команди в усьому світі.

1. Ви працюєте, не піклуючись про здоров'я компанії.

2. Шукайте роботу в іншому місці.

3. Внесіть розумні пропозиції ведучому, прем'єр-міністру та власнику та сподіваємось, що вони будуть прийняті.

Ви можете одночасно робити будь-яку комбінацію вищезазначеного.

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

Я працював у подібній ситуації, коли провідний розробник, який насправді був партнером у компанії, створив «ядро» програмного забезпечення, і за винятком близького друга, який працював безпосередньо з ним, іншим розробникам заборонено торкатися серцевина.

"Повноваження, що є", також створювали правила, як кожен модуль, могли мати лише одну таблицю бази даних, тому що вона чистіша. І внаслідок цього наявні спади були створені шляхом вибору "DISTINCT" з таблиць у базі даних, а не окремої таблиці.

Навколо пропливало чимало поганих патчів, оскільки команда з впровадження повинна була виконати роботу, і продукт не діяв би поза коробкою. Ці виправлення спричинили стільки проблем, скільки вони виправлені та були налаштовані (зламані) для кожної установки.

Мій підхід полягав у тому, щоб взяти одну невелику частину специфікації, яку ядро ​​не підтримує, і написати невеликий, добрий, загальний патч для цього. Щось, що задовольнило команду з впровадження, але не було настільки загрозливим, як "Нам потрібно повністю змінити своє мислення". Через ворожнечу між командою з впровадження та основними розробниками знадобилося кілька місяців, щоб переконати команду з впровадження, що мій підхід був кращим за їхні хаки. Але як тільки вони побачили, що я буду слухати їх і впроваджу додаткові корективи для їх підтримки, вони були в захваті і на моєму боці. Пройшов ще місяць, щоб провідний розробник прийняв виправлення, але колись він це зробив, це дійсно відкрило комунікацію між нами щодо кращих способів проектування інших частин системи.

Це ніколи не є короткою дорогою до зміни мислення людей, особливо якщо вам потрібно підтримувати з ними цивільні відносини. Але якщо підійти до цього правильно, ви можете завоювати повагу, не ображаючи свого начальника.

Сподіваюся, що це допомагає!

Дуже проста відповідь і рішення. Видається, що всі знають про проблему. Таким чином, ваше оточення, вказуючи на проблему, ні для кого не має користі. Насправді це просто змушує вас виглядати каламутним. Якщо ви хочете додати цінність, вам потрібно вказати на рішення та створити діловий кейс для зміни вашого рішення. Тоді ви можете вказати на проблему відповідним рішенням. Демонстрація також пройде великий шлях у доведенні вашого рішення. Звичайно, це може означати, що ви працюєте у власний час, але все залежить від того, наскільки це важливо і вам.

Перш за все, я настійно пропоную вам переконатися у своїх фактах, оскільки це проблема архітектури додатків, а не щось у конфігурації VPN. Я бачив, що неправильно налаштовані VPN викликають саме цю проблему. Ви точно знаєте, що програма так повільно знаходиться в офісі?

Якщо ви виключаєте мережу, я б пішов із пропозицією KiethS і попросив прем'єр-міністра перетягнути сторінку.

Це звучить як бізнес, або, принаймні, проект незабаром закінчиться. Не маючи виходу, я б спробував якомога швидше відійти від нього, наприклад, волонтер / запит на роботу над іншими проектами. Сподіваємось, що з часом ви витратите менше часу на цю катастрофу та більше на інші проекти, які мають шанс працювати. Ви не хочете, щоб вас вважали "хлопцем, який працював над проектом, який не працював". Вся справа в захисті своєї репутації.

Хоче власник хорошого товару чи ні? Я дуже підозрюю, що відповідь "Так" ... і тому вам потрібно говорити. Потрібно задокументувати поточну архітектуру, а потім (з хорошими недостовірними даними) показати, як виріб не відповідає правильним очікуванням продуктивності. Ви кажете, що всі ваші колеги знають, що це працює погано - ну ... а як щодо замовника? Що вони кажуть? Скористайтеся інструментом вимірювання продуктивності та визначте, що займає так довго. Багато інструментів навіть знизяться, показуючи, скільки часу займає кожен виклик функції. З усіх цих даних у вас повинно бути достатньо боєприпасів, щоб поговорити зі своїм керівником проекту та технічним керівництвом про те, чому все не так, як слід, і як можуть знадобитися деякі основні рефактори, щоб швидкість роботи продукту.

Тоді (лише після розмови з прем’єр-міністром та ведучим) цього ПОВИННО буде достатньо, щоб почати вносити деякі зміни. Якщо прем'єр-міністр на той момент не переконаний, то вам потрібно вирішити, чи справді це місце, яким ви хочете бути. Якщо так, то, можливо, зустріч з власником. Якщо ні, підготуйте це резюме.

Не забудьте документувати кожен крок.

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

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

Якщо це не виходить, ви можете спробувати поговорити з прем’єр-міністром, а потім власником.

Якщо жоден не працює, пропоную вам шукати нову роботу.

Чесність - і стільки такту, скільки ви можете зібрати.

Почніть з головного розробника і працюйте на своєму шляху, якщо вам доведеться. Постарайтеся залучити кращі сторони їх особистості - Якщо ви ведете розробник любить вирішувати проблеми / любить економити день / любить бути ефективним / і т.д. мали успіх у минулому як додаткова мотивація.

Якщо ти не робиш хвиль, ти, ймовірно, мертвий у воді.

Чи можна було б повернути проблеми до рівня, який вимірюється та нетехнічно, щоб керівник проекту та власник могли зрозуміти.

Наприклад, ви згадали про повільний час завантаження 3+ хвилин, я б припустив, що десь у специфікації є вимога до продуктивності, щось таке просте, як "сторінка повинна завантажуватися протягом 1сек". Щось подібне вимірюється і не може бути спростовано. Якщо першопричиною цієї проблеми виявляється хитра архітектура, тоді менеджер проектів та / або власник повинні вступити, щоб примусити деякі зміни.

Якщо ні, то у вас є систематична проблема у вашій компанії, коли початковий аналіз був зроблений неякісно і не існує достатнього процесу для вирішення подібних проблем. Розгляньте стрибаючий корабель!

Справжні чоловіки говорять без обурення чи емоцій. У цьому і полягає трюк.

Єдина вагома причина, що хтось може перехреститися з вами, щоб висловитись, це якщо ви зіткнулися з такою ненавистю:

СВІДОВИЙ РОЗРОБНИК НЕ МАЄ КЛЮЧУ, ЩО РОБИТИ. Я знав, що це станеться, але ніхто не слухав мене, бла-бла-бла.

де як

Модель коду помилкова, оскільки її важко підтримувати і повільно. Нам потрібно бути стратегічним щодо цього просування вперед і виправити ці два питання.

Перший - це битва за знищення, другий - це битва за мир, і в перспективі ви отримаєте шану, яку людина отримує за те, що вона є чесною.

Якщо керівник проекту сприймає це як передній план, що, звичайно, може вважати, що він може бути звільнений, тоді просто скажіть:

Не вважайте мене відповідальним за речі, за які я не відповідав. Я просто чесний.