Менеджер продовжує змінювати специфікацію вимог після кожної демонстрації [закрито]


21

Передумови мого робочого середовища

Мій менеджер не має досвіду та розуміння комп'ютерів чи програмного забезпечення. Цілком ймовірно, що він не бачив коду в будь-якій формі (навіть з фізичної відстані 10 футів або менше) у своєму житті.

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

На тесті Джоеля ми набираємо неймовірний бал 0.

Проблеми

  • Менеджер і часом інші «старші» продовжують змінювати специфікацію вимог. Зміни, які, якщо буде зроблено хорошу інженерію та не мають виправлених "виправлень", потребують змін у базовій конструкції.
  • Немає абсолютно нікого, хто дивиться на код (можливо, тому, що ніхто не знає, як це зробити, або навіть якщо це потрібно зробити), що означає, що ніхто не зможе:
    • Оцініть складність проблеми або витонченість рішення.
    • Запропонуйте вдосконалити підхід.
    • Оцініть якість коду.
    • Вкажіть, де код можна вдосконалити.
  • Багато жаргону використовується, що має сенс граматично, але не має сенсу будь-якого іншого способу.
  • Не відчуває себе, не поводиться чи працює як програмна компанія.

Питання

Що робити? Особливо щодо того, що не було б нікого, хто вказував би на поліпшення мого коду.

Оновлення

Щоб відповісти на запитання HLGEM (і, можливо, інші) про те, що я зробив, щоб спробувати виправити це. Я запропонував створити Redmine та запровадити контроль над усіма джерелами. Я сказав, що рекомендую розповсюджувати (git або mercurial), але також поговорять про централізовані та дозволяю команді приймати рішення. Відповідь полягала в тому, що все робиться і буде зроблено протягом тижнів. Я не бачив цього, ні мені невідомо, чи використовують його інші частини компанії.


36
щоб перемогти очевидну відповідь: РУН !!
keppla

3
Якщо у вас є щось основне, ви не говорите нам, що слід шукати нову роботу.
Захарій К

11
"Менеджер і часом інші" старші "продовжують змінювати специфікацію вимоги." Що ж, наявність специфікації набрала б вам 1 на тесті Джоела. : P
Р. Мартиньо Фернандес

11
Жодна організація не набирає балів менше ніж 2 на тесті Джоела виключно через нетехнічних керівників. Існує ряд речей, які ви та інші технічні члени команди можуть зробити без участі нетехнічних менеджерів для підвищення вашої оцінки. Ви не маєте виправдання звинувачувати це виключно в управлінні.
maple_shaft

6
Здається, у вас є команда з продажу як управління програмним забезпеченням, я співчуваю.
wildpeaks

Відповіді:


30

Коротка версія :

Біжи.


Дещо довша версія :

Якщо менеджер не знає, як запустити проект, і якщо старший йде разом з ним, то у вас немає шансів виправити речі.

Для управління проектами програмного забезпечення менеджеру потрібно щось зрозуміти щодо програмного забезпечення. Якщо менеджери цього не роблять, їм потрібно спочатку навчитися. Які ваші шанси ви могли переконати керівництво та старших (-ів), що вони все зрозуміли неправильно? Які шанси ви навчите їх чомусь?

Я колись був у подібній ситуації (тільки старших не було). Я кинув після страшного року, і ніколи не оглядався (крім огиди).


3
+1 для цієї цитати: "Якщо менеджер не знає, як запускати програму, і якщо старший йде разом з нею, то у вас поруч немає шансів виправити речі".
maple_shaft

17

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

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

Багато жаргону використовується, що має сенс граматично, але не має сенсу будь-якого іншого способу.

Знову ж, не звучить так незнайомо ;-)

Немає нікого, хто розуміє складність того, що мене просять втілити.

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

Просте рішення ескапістів - перейти на компанію. Але як інший варіант розглянемо реалізацію елементів тесту Джоеля. Хоча пункти від 5 вимагають більшої співпраці з керівництвом, пункти 1-4 такі, що ви могли просто їх налаштувати, не запитуючи нікого.

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


А як же хтось вказує на мої помилки? Допомагаю мені вдосконалюватися та вчитися.
Мисливець за джунглями

4
@ Jungle Hunter: Звичайно, було б легше опинитися в компанії, де все було легко налаштовано, всі вже дотримуються кожної уявної найкращої практики тощо, так що ви можете бути просто учнем і наслідувати інших. Але ви також можете вдосконалитись та навчитися багато чого, взявши на себе відповідальність та бути активною у вдосконаленні своєї компанії. Удосконалення та навчання в кінцевому рахунку у ваших руках. Інші люди можуть допомогти, але ваш начальник не повинен бути одним з них.
Joonas Pulakaka

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

@ Jungle Hunter: Я бачу, межа між скаргами та поліпшенням може бути нечіткою . Але ніколи не боляче схилятися до конструктивної сторони.
Joonas Pulakka

4
@Joonas: Я був у компаніях, де я впроваджував VCS, огляди коду, проводив семінари C ++ та інше, щоб покращити якість коду. І я був досить багато в компанії, як описує ОП. Якщо це безнадійний випадок, ви повинні визнати поразку і шукати роботу, де ваша боротьба винагороджується, дозволяючи досягти успіху.
sbi

16

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

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

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

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

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

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

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

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

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

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


1
Ця відповідь має дуже корисні частини. І деякі речі, які я вважаю неправильними щодо розуміння моєї ситуації. Мовляв, я згадую обидва випадки, яких ніхто не оцінить, коли це добре. Ніхто не вказував, коли я помилився. Я використовую управління джерелами, але в команді з 2-3 ніхто більше не займається. Код, коли це спільний доступ, ділиться за допомогою pendrives та Airdrop. Якщо ви читали коментар, я думаю, що я також згадував, що я встановив Redmine на своєму ноутбуці, який в кінцевому підсумку використовується тільки мною. І те саме з git. Намагався впровадити їх для всіх. Мій рівень, свіжий поза коледжем. Старший повинен кодувати, але ні.
Мисливець за джунглями

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

3
Перестаньте надавати їм код на мандрівниках. Якщо вони хочуть ваш код, скажіть їм, що він знаходиться в контролі джерела, і покажіть їм, як ним користуватися.
Гюго

1
@JungleHunter Коли вони запитають ваш код, скажіть їм, що ви перебуваєте на півдорозі зміни, яка не запуститься, але вони можуть отримати останню стабільну версію від контролю джерела.
Кірк Бродхерст

1
@HLGEM "Ти плачеш і скуголиш"? Набагато суворий, виступаючи лише за це.
Бен Х

6

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

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


Він просто дивиться на демонстрацію. Каже, давайте змінимо це на цей і на той спосіб. А тут потоп жаргонів.
Мисливець за джунглями

2
@Jungle, я б не вкладав жодної роботи в демонстрації, тому що вони неодмінно змінюються, як тільки він їх побачить. Він звучить як візуальна людина насамперед. Ви спробували скласти знімки екрана різних випадків використання для нього? Це може бути набагато простіше зібрати, ніж функціональні прототипи.
maple_shaft

@maple_shaft: Я думаю, що це відмінна ідея.
Мисливець за джунглями

1
@maple_shaft: Або, можливо, замість того, щоб набагато достроково доставити доставку до кінця. ;)
Мисливець за джунглями

1
Порада середнього школяра ...

4

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

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

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


1
Я говорив. Я запропонував створити систему квитків, ввести контроль над версіями, але йому все одно. Або зрозуміти. Або і те й інше. Я попросив поговорити з ним про наявність надійної специфікації, і він погоджується. Тим не менш, це змінює. Він не керований даними. (Ох і зняв наголос на текст із мого запитання.)
Мисливець на джунглі

2
@Jungle: Потім запустіть якнайшвидше.
sbi

1
Я погоджуюся з sbi, якби ви не просили вже вас збити, ви могли б законно просто вийти і зробити це самостійно. Ви вже втратили кімнату, і якби я був у вашій ситуації, я б почав шукати.
maple_shaft

3

Ваша проблема полягає в тому, що системи квитків та контроль за версіями - це ТЕХНІЧНІ питання, і вам слід займатися цим незалежно від залучення нетехнічного менеджера. Це слід вважати найкращою практикою в технічному плані, і якщо у них цього не встановлено, ви повинні взяти на себе це, щоб це сталося.

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

У мене також нетехнічний менеджер і мені вдалося збільшити показник Joel Test з 4 до 8 тільки тому, що я пішов, зробив їх і не просив дозволу.

Вашій групі потрібен сильний технічний лідер, і ніхто не підійшов до таблички.

Ознайомтеся з http://community.raldev.com/, вони мають спільне видання, яке прекрасно справляється з керуванням проектами Agile та відстеженням дефектів. Це одне лише збільшить ваш показник Joel і коштуватиме вам НЕ серверного місця або часу для налаштування.


Так! Ось я думаю, що головне питання. У нас немає сильного технічного лідера.
Мисливець за джунглями

2

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

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

Ласкаво просимо змінити вимоги, навіть пізно в розробці. Зміна гнучких процесів змінюється для конкурентної переваги замовника.

Але пристосовуватися до змін вимог означає також дотримуватися інших спритних принципів. На рівні менеджменту це означає, що менеджер повинен мати можливість прозоро представити замовнику, що всі такі зміни пов'язані з вартістю: або обсяг проекту повинен бути змінений, щоб задовольнити терміни, або терміни повинні бути зміщені (останні не рекомендуються).

Якщо це такий собі проект, коли ваш менеджер - це той, хто висуває всі вимоги, то вам слід діяти так, як він / вона ваш спритний клієнт, і пояснити їм те саме (сфера <--> термін компромісу) ).

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

Це кілька кроків, які вам абсолютно потрібно зробити, і, ймовірно, вам доведеться їх виконати самостійно:

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

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

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


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

У мене є git / mercurial для себе. Але я зараз роблю тестування вручну. Я повинен розглянути тести автоматизованого блоку.
Мисливець за джунглями

1

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

Менеджери не зобов'язані розуміти код або складності. Необхідність розуміння, ресурсів, вартості та ризику.

Версії вихідного коду, якість коду, складність тощо - це відповідальність ПМ або Старший розробник.

Рішення полягає в тому, щоб:

1-Визначте структуру проектної групи та їх обов'язки

2-Навчіть менеджера у випадках відмов програмного забезпечення, спричиненого поганим управлінням - тримайтеся подалі від технічних деталей. Ви можете знайти кілька прикладів за допомогою googling.


"Тримайтеся подалі від технічних деталей." Я спробую чинити опір. ;) Дякую, що вказали на це.
Мисливець за джунглями

0

Особливо щодо того, що не було б нікого, хто вказував би на поліпшення мого коду.

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

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


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

0

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

Варіант 2 - дайте їм те, що вони хочуть. Коли вони скаржаться на те, що ви говорите "але це те, про що ви попросили"


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

@jungle мисливець - Не у кожного є можливість кинути роботу, іноді доводиться виходити з ситуації. Я знайшов найкращий спосіб впоратися з божевіллям - повернути його божевільним людям. Тільки самі божевільні можуть сперечатися проти власної божевільності. Щасти.
jqa
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.