Що можна зробити, коли "вести приклад" не працює? [зачинено]

Я працюю у великій компанії (8000+ працівників) вже майже 2 роки, і мене прийняли на роботу відразу після того, як я закінчив навчальний курс.

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

Щоб бути більш чіткими, ми маємо:

• Застарілий інструмент управління джерелом (Visual SourceSafe)
• Звичайні старі файли, які підтримують лише повну перебудову
• .def файли, які повинні підтримуватися вручну та окремо для всіх існуючих архітектур
• монолітні заголовки файлів і проектів з дуже мало різних файлів (але в кожному є близько 3000 рядків коду, який іноді піклується про дуже різні завдання)
• жодне використання "нових" мовних засобів (ну std::stringце не нове, але ніхто, крім мене, не використовує його)

Кілька місяців тому я вирішив щось зробити, створивши нове середовище компіляції. Я міг би отримати додаткові нарощування для надійної роботи, швидший час компіляції, кращі структуровані проекти, автоматичне створення .defфайлів. Я навіть створив міст з / в Git до / з Visual SourceSafe.

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

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

Я навіть намагався залучити до змін деякі мої колеги. Але поки що успіху немає.

Ви вже стикалися з подібною ситуацією? Що робити, коли "вести приклад" не працює?

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

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

Уникайте гнилого м’яса : Деякі ніколи не будуть співчувати вашим ідеям. Залиште їх убік.

Зростайте до критичної маси : знайдіть людей, які співчувають вашим ідеям. Виграйте один за одним. У якийсь момент, якщо буде досягнута критична маса, все більше і більше людей наслідують ваш приклад добровільно.

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

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

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

Ви коли-небудь зупинялися, щоб вважати, що ви можете помилятися?

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

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

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

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

• Значна підтримка управління

• Загальноприйнята компанія

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

• Навчання потрібно планувати і встановлювати, щоб переконатися, що навіть найрозумніші розробники знають, що роблять

• Навіть якщо передбачити годину навчання, для 8000 розробників х € 50 / год = € 400000 вартість навчання. Це більше грошей, ніж моя одна команда з розробки програмного забезпечення отримує бюджет на цілий рік за зарплату, програмне забезпечення та обладнання. Це виняткова інвестиція, яку ви пропонуєте.

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

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

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

Звичайні старі файли, які підтримують лише повну перебудову.

Створіть власні файли на місцевому рівні та покажіть, наскільки ефективніше ви можете працювати з ними.

монолітні заголовки файлів і проектів з дуже мало різних файлів (але в кожному є близько 3000 рядків коду, який іноді піклується про дуже різні завдання)

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

жодне використання "нових" мовних засобів (ну std :: string не є таким новим, але ніхто, крім мене, не використовує його)

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

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

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

На додаток до Ліонеля Барета (з яким я здебільшого згоден) врахуйте також можливу мотивацію до опору.

• Оцініть вартість фактичного процесу
• Оцініть вартість процесу, як він буде як ваш

Але також:

• Оцініть вартість зміни терміну
  • Гроші, які потрібно витратити на налаштування нового середовища для будь-кого
  • Час витратити на те, щоб навчити усіх звикати до нового режиму (це може бути вам легко, але не так просто для людей, які не знають, що ви робите)
  • Минув час, необхідний для управління змінами без перешкод.

У мене є підозрюваний: скільки у вашій компанії таких людей, як ви за рівнем віку та культури (я чоловіки "школа" та "тип школи")? Скільки таких людей, як ви, як очікується, приймуть на роботу в найближчі 2/3 роки, а скільки вийде на пенсію або змінить свою роль в організації?

Мій підозрюваний полягає в тому, що ви перебуваєте в становищі з недостатньою силою для зміни компанії. У цій ситуації або компанія змінить вас, або «вишле» вас (У сенсі це стане вашим власним бажанням піти), якщо ви не зможете чекати більше часу.

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

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

Стратегія 1 Просто роби це

Стратегія 2 Використовуйте силу вірусного маркетингу

Стратегія 3 Створення кишені майстерності

Стратегія 4 Нейтралізуйте Bozos

Стратегія 5 Відволіктись від перебоїв

Стратегія 6 Стань неоціненною

Я підсумую статтю як "Зміни повинні починатися з вас".

На жаль, люди застрягають у колії і розвивають менталітет, що «це працює, всі добре його використовують, навіщо міняти» І це надихає.

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

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

Однак, можливо, ваші ідеї та робота можуть бути проігноровані, і ситуація залишиться такою, якою вона є.

Потрібно викладати свою справу так, щоб стати на ваш бік босом. До речі, подібні зміни пропонуються технічним директором або керівником проекту, тому потрібно буде взяти на себе зобов'язання над проектом. (В якості альтернативного варіанту ви можете запропонувати технічний аудит. Сторонній чоловік, ймовірно, скаже те саме, що і ви, але матиме більше ваги.)

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

Перші гроші, вам потрібно довести, що поточна установка коштує йому грошей. Яка вартість / годину розробника і скільки годин швидше складатиме його час? Зробіть математику. Крім того, складіть статті чи свідчення щодо ризиків поточного конвеєра коду та покажіть йому страшні цифри: "через практику SourceSafe / Bad Coding наша компанія втратила $ XXXK".

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

Нарешті, вам слід запропонувати план зміни кодової бази, розділеної на невеликі проекти, з віхами та розподілом ресурсів. Насправді ви продаєте себе як менеджера проектів, і зміни, як обов'язкові, мають суцільний конвеєр коду.

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

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

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

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

Досконалість - це ставлення та світогляд.

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

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

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

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

Мені здається, ти риба поза водою. Ідіть, знайдіть своє тіло океану і поплавайте!