Чи повинен (молодший) розробник намагатися просунути кращі процеси та практики в своїй команді з розвитку / ІТ?

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

Моя команда досить маленька і дещо нова (<3 роки). Їм не вистачає:

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

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

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

Поки що хороші відповіді, але вони не охоплюють усіх підстав.

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

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

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

Це був фантастичний фрагмент дизайну програмного забезпечення.

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

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

Цей архітектор був університетським професором з кількома книгами на цю тему. Він ніколи не працював ані дня програмістом над комерційним проектом.

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

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

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

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

Так, але з великою обережністю!

Дозвольте мені уточнити це.

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

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

Проблема

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

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

Шлях вперед

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

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

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

Зараз трапилося три речі:

• ви вдосконалили систему,
• Ви набули досвіду щодо зміни системи
• команда побачила, що ви успішно змінюєте систему.

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

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

Так, ти можеш. АЛЕ ...

Ви повинні бути обережними.

На початку своєї кар’єри (дуже давно) мені пощастило / не пощастило потрапити в проект, який пройшов кілька місяців, як «Юніор».

Як перше, що я помітив, не було (OMG) сховища коду! Всі злиття коду проводилися вручну, надсилаючи поштові файли один одному поштою.

Тож я пішов до свого (теж нового) менеджера і запропонував нам мати сховище. Відповідь була: Гаразд, організуйте….

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

Коли я все це налаштував, (шок) ніхто не хотів ним користуватися. Тож я спробував підштовхнути справи і, на щастя, мій менеджер зрозумів, що це важливо, тому я мав підтримку.

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

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

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

Вся команда повинна вирівнятися.

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

Як і в коді, те саме для процесів розробки: потрібно постійне вдосконалення.

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

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

Чи варто домагатися (молодшого) розробника, щоб спробувати намагатися досягти вищезазначеного, як пройде час?

Так, завжди варто докласти зусиль, щоб спробувати покращити справи. Ти найкраще знаєш, з якими проблемами ти стикаєшся.

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

Тому що зрештою, якщо ти не є частиною рішення, ти є частиною проблеми.

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

• Не протягом перших тижнів: використовуйте цей час для:

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

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

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

• Не суди. Не вимагайте. Попросіть його і уважно слухайте: Це момент, коли спілкування є критичним, і ми, програмісти, зазвичай не дуже хороші в тонких нюансах. Існують методи, які допоможуть . Легко продовжувати наполягати на нашій ідеї, а не зосереджуватися на відповіді. Спочатку переконайтеся, що вони відчувають, що ви отримали їх бали. Зрозумійте, що почуття важливі. Що ця зміна змушує їх відчувати? страх? недостатність? гнів? розчарування? сподіватися? Ледачий? Дурний? (Ніколи не робіть людей дурними). Звичайно, ви б задавали багато питань раніше, і це запобіжить безлічі помилкових кроків.

• Ведіть за прикладом : скаржитися легко, створити зміни важко. Покажіть результати, і люди вам повірять. Якщо вони не використовують тест, ви можете написати свої тести на одиницю. Якщо люди не документують, ви можете поділитися деякими документами google з командою. Зрозумійте, що "Гаразд, зроби це" - це один з найкращих можливих сценаріїв, і тоді його потрібно виконати. У цьому випадку потрібно подумати, які ресурси вам потрібні . Приклад: дайте мені невеликий екземпляр Amazon та дві години від адміністраторів для сервера Jenkins

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

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

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

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

• Розкажіть про час, у який ви змінили команду.
• Ну, я був у такому місці, якщо вони мали дуже старомодні практики. Дуже багато людей не були задоволені цим, і продуктивність мала велику можливість покращитись. Тому я запропонував зробити швидкий експеримент із ретроспективами, ми зробили X, і Y, і в результаті ми отримали цей чудовий вимірюваний результат ".

Так. Але не те, що ви пропонуєте.

З вашого списку тести "Елемент / Інтеграція" - єдиний предмет, на якому можна прогресувати.

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

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

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

Це залежить від:

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

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

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

Ви не згадали про управління вихідним кодом. Чи є у вас сховище вихідного коду (git, svn, cvs, ...)? Стратегія позначення та розгалуження? Це прості кроки, які може зробити новачок. Прочитайте, які проблеми ці кроки (спробуйте) вирішити, і як це допомагає вашій компанії зменшити витрати (саме це зацікавило менеджмент).

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

Щодо scrum, краще читайте про "Екстремальне програмування" (XP). Scrum заснований на багатьох ідеях XP і додає навколо них формалізований процес - поняття XP все ще можна використовувати без цього процесу.

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

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

На початку задайте питання

Читаючи ваш список, я б запропонував наступні питання (поверніться до свого списку, щоб побачити, як вони підходять):

• Як я бачу, яку роботу просять власники бізнесу?
• Ви пробували [Scrum]?
• Хто власник продукту для цього?
• Які там ролі?
• Що робить [ця роль]?
• Яка роль відповідає за [цю діяльність]?
• Ви пробували щоденний стендап?
• Як я передаю свої перешкоди решті команди?
• Як дізнатися, над чим працюють інші члени команди?
• Чи слід ставити [це] в інструмент відстеження проблем?
• Як нам написати [це] в інструменті відстеження проблем?
• Коли [це] трапляється, чи слід ставити його в інструмент відстеження проблем як [що]?
• Як ми тестуємо?
• Як ми записуємо тести, щоб інші могли повторно використовувати їх?
• Ви пробували [JUnit]?
• Де це [документально] задокументовано?
• Ви пробували [MediaWiki]?

Замініть речі у [дужках] у відповідних випадках, щоб питання мали сенс чи відповідали вашим пріоритетам. Подумайте про переформулювання, якщо моє формулювання не відповідає вашому стилю.

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

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

Пізніше зробіть кроки

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

Якщо у вас є перешкоди (і якщо ви припускаєте, що ви не можете поділитися в складі стадіону), надішліть команду про допомогу.

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

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

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

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

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

Зрештою, ти будеш старшим

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

Коротка відповідь : Ні, з усіх причин, викладених в інших відповідях. Навіть будучи середнім чи старшим розробником, краще краще спершу розібратися, коли приєднаєтесь до нової команди.

Пропоноване рішення :

1) щоразу, коли ви бачите щось, що відчуваєте, слід вдосконалювати, враховуйте це! (у зошиті, в цифровій записці ...)

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

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

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

• Створювати культурні зміни важко .
• Тим більше, якщо вас сприймали як "молодшого"

Все інше може слідувати, якщо є засоби для постійного вдосконалення .

Мій підхід до досягнення цього:

• Задокументовані процеси та процедури
• Ретроспектива з командою, чиї дії - це зміни в технологічній документації.

Я думаю, якщо у вас немає спринтів, ви ще не маєте регулярних ретро. Все, що вам потрібно, - це розмова з командою, а потім дії, які потрібно зробити.

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

Можливо, ви починаєте з таких розмов, як спеціальні, а потім пропонуєте регулярні ритуали.

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

Деякі міркування:

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