Як запропонувати зміни як нещодавно прийнятого працівника? [зачинено]

Мене нещодавно найняли у велику компанію (тисячі людей, щоб дати уявлення про розмір). Вони сказали, що найняли мене через мою суворість і через те, що я, незважаючи на свою молодість (мені 25 років), пережив себе як програміст C / C ++.

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

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

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

Дякую.

Оновлення

Дотримуючись ваших дорогоцінних порад, я зміг запропонувати зміни, і тепер я відповідаю за команду, яка повинна створити та розгорнути Subversion: D Дякую всім вам!

Через 6 місяців

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

Я був у подібній ситуації на своїй попередній компанії, де був 5 років. Коли я приєднався в 2004 році, вони:

• все ще використовують Microsoft Access для своїх баз даних (навіть критично важливих для бізнесу)
• використання Visual Basic 6 або Access / Excel VBA для розробки
• використання багатьох третіх сторін замість використання власних ресурсів розвитку (менеджери бізнесу керували власними проектами розвитку, і 90% часу виставляли контракти без участі ІТ)
• Гасп немає контролю над версіями.

Коли я пішов минулого року, компанією були:

• використовуючи виключно .NET і C #
• вигнали всю розробку доступу
• використання SVN для контролю версій
• мав 2 надійних ящика SQL Server і мігрував існуючі бази даних Access у SQL
• всі розробки проходили через внутрішні команди та виходили на тендер, лише якщо ресурс був обмежений

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

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

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

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

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

Моя рада вам:

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

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

Швидше, тому що ви дешевші.

Ви коли-небудь були в подібній ситуації

Так.

які поради ви б мені дали

Залишати.

Чи є тонкий спосіб змінити речі, не ставши тут чорними вівцями?

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

Або я просто повинен відмовитись від своєї пристрасті та енергії?

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

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

Це займе час. Просто не стягуйте людей з місця комфорту занадто швидко.

Сумно, але саме тому ваше тут, а вони - ні.

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

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

Я старий (51 рік) і у мене була така сама проблема на кожній роботі, яку я коли-небудь мав. Можливо, це просто виходить від того, що завжди бути найрозумнішим хлопцем у кімнаті! :-) Серйозно, однак, коли ти знаєш, як це зробити правильно, а вони цього не роблять, ти часто думаєш: "Гей, я покажу всім цю нову та вдосконалену техніку, і всі вони будуть вражені та захочуть заскочити до його використання ". Але в реальному житті 90% часу ти показуєш людям кращий шлях, і вони придумують довгий список виправдань, чому краще те, що вони робили це все разом. Коли ви продемонструєте, що їх причини не є дійсними, вони з’являються нові, ще більш ламерні причини. У мене було багато разів, що я

Навіть якщо ви справді геній, ви повинні визнати, що ніхто більше не знає, що ви геній, поки ви не докажете це. Мені пригадується Крис, мій друг, який розпочав нову роботу, провівши 10 років в одній компанії. Незабаром після початку нової роботи він був на нараді, де вони обговорювали якусь технічну проблему, і він почав пропонувати запропоноване рішення. Потім хтось інший перебив і сказав: "Ага, дякую. Боб, як ти думаєш?" Спочатку він був роздратований: Він знав правильну відповідь, але ніхто не хвилювався! Натомість вони пішли з думкою того, хто знав набагато менше, ніж він. Але потім він зрозумів, ей, на моїй старій роботі я створив собі репутацію того, хто знав, про що він говорить, тому коли я розмовляв, люди слухали. Тут я ще не маю репутації, тому нікого не цікавить те, що я думаю.

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

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

Знайдіть союзників, які також хочуть покращити компанію.

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

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

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

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

Використовуйте свої більш сучасні знання, щоб стати людиною, яка світить, і тоді люди почнуть запитувати, як ви це робите. Коли ПК вперше вийшов на робоче місце, я працював у державному аудиторському агентстві. Люди похилого віку були дуже проти того, щоб мати власні комп’ютери (адже це була робота для секретарів). Юніори схопили всіте перші комп’ютери і почали робити речі, які старші люди не могли зробити з Lotus 1-2-3 та Harvard Graphics. І раптом, старші люди зацікавилися, оскільки молоді хлопці привертали увагу старшого керівництва.

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

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

Наприклад, моя команда підтримувала, оновлювала та використовувала 16-бітну утиліту DOS для тестування. Утиліта була королівським болем для оновлення, оскільки додаток розсунуло межі 16-розрядного посилання на той момент, коли, якщо ви додали код, вам доведеться видалити щось інше, щоб воно вмістилося. На запитання, чому ми витрачали стільки часу та енергії на 16-бітний код, їх відповідь була "тому що нам потрібно, щоб він працював у DOS, щоб ми могли запустити його із завантажувальної флешки". Я намагався переконати їх перенести утиліту на 32-розрядний Linux, але керівництво не хотіло вкладати час для цього (у нас уже було занадто багато роботи, як це було). Отже, я пішов уперед і переніс утиліту в нерабочий час (15 хвилин тут і там в обід, у вихідні дні, або поки я чекав, щоб інший код скласти). Протягом декількох місяців У мене утиліта була повністю перенесена, покращена всіма видами речей, з якими не впоралася оригінальна 16-бітна програма, та завантажувалася з флешки Linux. Люди помітили, коли я почав його використовувати, і коментували, як я міг би швидше зробити роботу і як моя утиліта генерувала кращий вихід налагодження. Досить скоро керівництво почуло про це. Як тільки вони побачили переваги (і найголовніше, що робота вже зроблена), вони вже не були проти ідеї.

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

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

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

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

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

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

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

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

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

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

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

ДОПОЛНЕННЯ: Якщо ваш менеджер ставить під сумнів вашу поведінку ... не робіть цього, якщо він не відчуває, що ваша продуктивність залишається принаймні "топ 25%", я переконайтеся, що ваш начальник задоволений вами, перш ніж ви почнете намагатися придумувати всі види розумних виправлень, які підштовхують вас вище до цього топ%, або він подумає, що ви витрачаєте час. Якщо ви викидаєте нові утиліти та рішення, отримуючи позитивні відгуки про ефективність, проте він все ще наполягає на мікроменеджменті, у вас можуть виникнути проблеми, що не входять у рамки цієї теми.

Вписатися в.

Як ви сказали, ви не хочете бути чорною вівцею. Однак, оскільки ви (як і я) хочете додати деякі корисні зміни:

Додайте значення у фоновому режимі.

Налаштуйте кронштейни, щоб перевірити код людей у ​​svn / hg / git. Створіть власні інструменти у свій час, які можуть наочно покращити зусилля щодо розвитку. Зокрема, ви хочете вдосконалити компанію, щоб ви могли показати своїх літніх людей у ​​власній кабіні. І ось чому:

Вау-фактор

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

Ось моя порада.

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

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

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

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

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

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

Ps, мені теж 25 і знаю, як ти себе почуваєш. Ви, напевно, набагато більше прагнете вчитися та пробувати нові речі, ніж ваші колеги. У будь-якому випадку, треба повернутися до цієї роботи .NET4, яку я ввожу;)

Читайте, як робити речі, коли ви лише грунт Джоела Спольського.

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

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

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

Робота з управлінням; не "йдіть ізгоєм". Працюйте в рамках процесу і вкладайте речі в терміни, які люди зрозуміють, як-от "впровадження svn займе нам місце на сервері, два дні до установки, і нам потрібно створити резервну копію, але ми отримаємо x, y, z , що може заощадити нам багато грошей ".

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