Як я можу змінити неохайну культуру компанії? [зачинено]

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

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

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

Тепер цю конкретну проблему легко вирішити за допомогою MessageBox.Show("DO NOT GIVE TO CLIENTS!");. Однак ця проблема свідчить про набагато глибшу проблему: культура нашої компанії неохайна. Неслухняне програмне забезпечення в порядку, і неохайні процеси в порядку. Не хвилюйтесь про майбутнє - докладіть достатньо зусиль для того, щоб він ледве працював зараз, покладіть двійкові файли у .zip файл та відправте його. Досить добре для роботи уряду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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