Я менеджер. Як я можу покращити робочі стосунки та спілкування з програмістами? [зачинено]

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

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

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

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

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

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

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

• Чому? є дуже важливим питанням - майже будь-яка фактична відповідь має "чому" за цим, і те, чому "може", може бути важливішим, ніж власне питання. До цього є кілька дотичних:
  • Розробник Чому - Розробники матимуть багато відповідей, які абсолютно не мають сенсу для управління. Я, звичайно, так і зробив, і один із способів я потрапив в менеджмент - це дуже добре роз'яснювати команди "нащо" в термінах, що менеджмент міг зрозуміти. Якщо у вас немає «динаміка для вундуків», ви можете навчитися говорити прислівниками, переглянувши їхні відповіді на питання, чому виникає питання у більш поширених метафорах. Тримайте це, поки ви обидва не зрозумієте і не домовитесь про те, що відбувається.
  • Менеджмент Чому- ваше «чому» так само важливо. Для чого потрібні оцінки часу? Для чого ви їх використовуєте? Наскільки накрученими ми будемо як компанія, якщо вони зависокі чи занадто низькі? Це речі, які ви, як менеджер, мабуть, добре розумієте, але це все вуду для розробника. Хитрість полягає в тому, що розробник може не запитати. Керівництво попросило у нього щось, і він збирається зробити все можливе, щоб бути точним, своєчасним і продуманим - але якщо він не знає "чому", він може оптимізувати способи, ви б хотіли, щоб він цього не зробив. Запропонуйте, чому, і попросіть його зробити те ж саме - перегляньте відповідь у власних умовах.

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

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

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

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

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

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

І ось такий, який для мене надзвичайно важкий, але чудово працював, коли я можу це зробити - будьте в курсі різниці між інтровертами та екстравертами . Цілком ймовірно, що ви екстраверт - саме тому ваша робота здавалася гарною, а позиція в розвитку - ні. Розробники здебільшого - інтроверти. "Інтроверт" не означає "не можу спілкуватися", але це означає, що їхня картина, процес і швидкість суттєво відрізняються, а потяг до постійного спілкування практично не існує. Плануйте в часі і тихому (але розкладеному) просторі, щоб випускати думки, засновані на інтроверті. Багато моїх інтровертних друзів говорять мені, що вони просто чекають, коли я "заткнуться на 5 хвилин", щоб вони змогли скласти думку та відповісти. Ось '5 екстравертів повинні знати про інтровертів та Rands in Repose on Nerd Cave - особливо смачний для розробників приклад того, що чудово підходить для інтровертів . Ранди доволі фантастичні, до речі. Сам він вундеркінд, тому на нього звертається з фокус-розробником, який може бути відкладений, якщо це не ваш стиль, але він смішний і має дуже гарну думку про розвиток команди.

Я думаю, що найпопулярнішими речами моїх улюблених менеджерів були:

• вони були так само глибоко віддані і схвильовані щодо проекту, як і я (якщо не більше)

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

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

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

• вони були в курсі моїх особистих цілей і зацікавлені включити їх якомога більше

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

• завжди був час на тиждень (можливо, не в даний момент), щоб пояснити велику картину

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

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

Найпростіша частина спочатку: у вашому пості є технічний червоний прапор: я здригнувся від вашої згадки про "помилкові оцінки" - це оцінка, вона НЕ МОЖЕ БУТИ ПОМИЛЕНА , тому її називають оцінкою. Це може бути трохи відключено, може бути відключено багато, тому це називається кошторисом. Якщо ви приймаєте оцінки як євангеліє, це стане однією з головних проблем, з якими стикаються у вашому стилі розробники.

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

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

І що б ви не робили, НЕ задавайте їм питань, на які насправді не хочете знати відповіді, - посилаючись на "помилкові оцінки" вище ;-). Це криптоніт розробника.

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

• 5 років як прем'єр-міністр, і не знати, який тип ПК потрібен розробнику, викликає жахливість.
• Змусити розробника відмовитися від поганих умов праці як вашого першого справжнього червоного прапора, божевільно.

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

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

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

"Ми втратимо нашого найкращого хлопця, якщо ти щось не зробиш"

Це повинен бути червоний прапор №2.

Як менеджер, я впевнений, що ви чули про kaizen , один із принципів виробничої системи Toyota, що означає постійне вдосконалення .

Ви визнали, що у вас є проблеми, тож це чудовий початок.

У Kaizen є п'ять основних елементів:

• Кола якості : Групи, які збираються, щоб обговорити рівень якості, що стосується всіх аспектів роботи компанії.

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

• Робота в команді : Сильна компанія - це компанія, яка збирає разом кожен крок. Kaizen прагне допомогти працівникам та керівництву дивитися на себе як на членів команди, а не як на конкурентів.

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

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

( Джерело )

Якщо ви довго заглядаєте на це, константа над цими елементами - це акцент на командній роботі та зворотній зв'язок.

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

Отже, моя перша порада:

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

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

І, нарешті, хоча тут я бачив деякі критики щодо цього, я б рекомендував вам прочитати книгу під назвою «Міфічна людина-місяць: нариси програмної інженерії» . Книга про досвід Фреда Брукса в IBM під час управління розробкою OS / 360. Хоча декілька речей тут і там можуть бути датовані, це початковий крок для розуміння того, як працює процес розробки складного програмного забезпечення. С.Лотт наводить маніфест "Agile" , який я особливо не захоплююсь цим, але його також варто прочитати.

Прочитай це:

http://agilemanifesto.org/

• Індивіди та взаємодія над процесами та інструментами

• Працює програмне забезпечення над всеосяжною документацією

• Співпраця з клієнтами щодо узгодження договорів

• Відповідаючи на зміни протягом наступного плану

У багатьох випадках організація (тобто ваш начальник) вимагає від вас

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

• створити надмірну, малу вартість, невикористану документацію.

• брати участь у комплексному контролі за змінами a / k / договірних переговорів. Кожна зміна користувача вимагає складного ритуалу, щоб "якість" та "пріоритетність" змін. Дійсно, справа у всьому "заморожуванні" - запобіганні змін.

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

Можливо, проблема не у ваших особистих навичках спілкування.

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

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

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

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

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

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

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

• М абітурієнт більше, ніж керувати.
• А Llow членів команди , щоб висловити свої думки і проблеми. Будьте всі вуха до цього. Візьміть конструктивні.
• N ніколи НЕ зраджує член команди, граючи розділяє політику. Ця стрілка спрацьовує швидше і мовчки.
• А нгер ні. Ніколи не майте гримасів на обличчі, коли ви зі своєю командою, будьте що може. Це справді важко.
• Г енно і відкрито оцінюйте переможця за його добру працю. У той же широті дуже м'яко і тактично критикують роботу не людину за будь-які кривди, а людину, яка відповідає, ізольовано, а не відкрито.
• E ncourage власності і лідерство в кожній людині. Це підвищує мораль і відданість людини, тому що він почуватиметься поважаним.
• R OAM навколо з вашою командою один раз в той час. Це спонукає / збільшує зв’язок у членах команди.

Бажаю удачі у ваших щирих починаннях :)

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

Я добрий хлопець Теорії-Y, і більшість «знаючих працівників», як правило, є; Даючи шанс, нам подобається наша робота, і хочемо її зробити добре. Однак недоліком робочого місця в «Теорії-У» є те, що може бути не відразу зрозуміло, що існує проблема, тому що люди, бажаючи зробити добре і, таким чином, не бажаючи робити хвилі, знайдуть шляхи вирішення цієї проблеми або просто ігнорують її. Це призводить до розчарування, яке згодом вибухає на обличчі всієї команди. У магазині, керованому менеджером Theory-X, певно, будуть хлопці, які скаржилися набагато раніше; працівники лише в ньому за гроші, тож якщо робота смокче більше, ніж зазвичай, вони захопляться.

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

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

Якщо говорити про Agile; моя перша робота була в невеликій компанії, і "малим" я маю на увазі, що вся фірма не могла створити команду софтболу. Коли я починав, було чотири програмісти, і це скоротилося до двох, перш ніж я пішов. Засновник, президент, генеральний директор та 95% акціонерів компанії керували ним залізним кулаком, і він був єдиним джерелом планування в організації, тобто мало. Бос був трудоголіком і очікував, що всі інші будуть такими ж; Все, що вам довелося дати, не було більш-менш його очікуванням, і за це він виплачував зарплату початкового рівня людям, які працювали на нього десятиліття.

Я покинув цю компанію і почав працювати в іншій фірмі, яка робила речі ДУЖЕ інакше; вони практикували базову методологію SCRUM Agile, щодня складаючи щоденні склади, парне програмування, спринтерські команди та ретроспективи. Протягом одного дня кожні два тижні на початку кожного спринту ми нічого не робили, однак планували роботу на наступні два тижні. Для великого шматку іншого дня ми нічого не зробили, окрім як озираємось на те, що ми зробили, і знаходимо шляхи вдосконалення як команда. Поруч зі мною сиділи розробники, які були MVP Microsoft, які виконували роботу та заохочували та доповнювали те, що я робив.

Ніч. І. День. Основна відмінність? По-перше, я не відчував себе так, як від мене очікували вбивства за проект; Основним принципом Agile є стійкий темп розвитку. По-друге, я мав голос у вирішенні питання, як від мене очікуватиму робити свою роботу. Мені довелося виконати роботу, але якби у мене з’явилася «печія» над тим, що я повинен був очікувати, що я вийду в наступному спринті, я міг би озвучити цю думку, і це було б почуте і надавалося ваги. Якби я відчував, що є кращий шлях, я міг би так сказати і це розважило б.

Щодо пошуку рішень та вирішення проблем, ви повинні бути обережними, щоб не виглядати так, як працюєте зверху вниз. Для комп’ютерів; скажімо, ваш RMR (щомісячний дохід за місяць) дозволяє компанії лише оновити чотири комп'ютери за два тижні. Перші чотири комп’ютери не всі повинні переходити на провідників та старших; вони повинні йти до людей з найповільнішими комп’ютерами. Якщо ви даєте бонуси команді, не даруйте їх "нашим цінним старшим та лідерам, без яких це не було б можливим"; КОЖНО у вашій команді розробок це зробило. Якщо молодший має скаргу, вислухайте його; тільки тому, що він молодший, не означає, що він нічого не знає.

Поліпшення відносин:
Просто був важкий проект? Дайте їм потім перерву. Час відпустки, щоб відпочити, затамуйте подих.
Законопроект кодерів Ці речі є даною. Основні речі, про які слід говорити. Якщо ви порушите ці дії, ви зловживаєте кодовими клавішами.
Тест Джоела я згоден з більшістю з них. Але деякі дійсно залежать. Якщо вас не вистачає, ви, ймовірно, ускладнюєте життя своїм програмістам, тоді це потрібно.
Технічна заборгованість . Таким чином, ви можете наполягати на завершенні, але ви повинні усвідомити, що, скорочуючи кути, ви несете технічну заборгованість, яка потребує більше часу на останню дату, щоб виправити. Якщо ця дата з’явиться до кінця проекту, ви насправді викрутили.
RSA анімація: МотиваціяЦе фантастичний біт, який дійсно показує, як мотивувати знаючих працівників.
Вільний день, щоб кодувати те, що вони хочуть. З відео RSA. Не пам’ятайте ім'я, але компанія, яку він згадує, на своєму сайті має коротке пояснення. Здається, це гарна ідея для мене. У більшості магазинів є речі, про які всі знають, що вони розбиті, але ніхто не встигає виправити, і це не є великим пріоритетом. Це дозволяє їм вирішувати технічну заборгованість. Це також дозволяє їм демонструвати свої блискучі ідеї.

А для любові до Бога спробуйте дотримати 40-годинний робочий тиждень. Також флексим. Flextime може скласти цілий світ фігня. Принаймні для мене.

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

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

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

Удачі.

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

З мого досвіду, найбільш важливим фактором, який мені подобається або не подобається моєму менеджеру, є те, якщо він / вона розуміє розвиток загалом і розуміє роботу, яку я роблю. Тут наведено деякі позитивні результати:

• Мені не доведеться витрачати занадто багато часу, щоб обгрунтувати, чому зміна триватиме так довго або не може бути здійснена. Ну, технічно, будь-які зміни можуть бути здійснені, і вище керівництво зазвичай вимагає впровадження будь-яким способом. Але принаймні в такій ситуації ваш прямий керівник стоїть на вашому боці, просячи більше часу (замість того, щоб вас штовхати чи спалювати).
• Я знаю, що у мене є більший шанс отримати підтримку у випадку поганої ситуації (злом WTF, виробничий випуск тощо). Зазвичай, нетехнічна особа схильна звинувачувати розробника в такій ситуації, тоді як хороший менеджер РОЗУМОВЛЯЄ, що відбувається насправді, і підтримує його / її розробника (а не просто знає чи готовий сприймати це таким чином, щоб він був приємним).
• Я знаю, що мою роботу та ефективність слід оцінювати належною людиною.

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

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

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

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

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

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

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

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

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

По-третє, подумайте, які навички емоційного інтелекту у вас є. Емоційна розвідка для керівників проектів: Навики, які вам потрібні для досягнення видатних результатів Ентоні Мерсіно, були б книжковою рекомендацією, яку я отримав вчора з обіду та дізнайтеся про еквалайзер. Якщо ви дійсно хочете заглибитися в психологію, то тут можуть використовуватися різні інструменти профілю особистості, наприклад, Enneagram, соціальні стилі та MBTI.

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

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

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

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

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

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

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

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

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

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

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

Хороші посилання на один на один - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Короткий і солодкий. Excel у тому, що ви робите - це породжує спілкування.

Що означає чудове для ваших розробників? .. Читайте, перечитуйте, так, навіть вивчайте PeopleWare

Всі чудові ідеї та коментарі в публікаціях вище!

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

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

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

Ця ідея аж ніяк не є чарівною кулею, але є хорошим фундаментальним шматком головоломки. Не тільки ваші товариші навчиться краще спілкуватися один з одним, але і бонус у тому, що вони почнуть краще розуміти та поважати ВАШУ роботу (спілкування лежить в основі прем'єр-міністра).

Просто мої 2 біти :)

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

Візьміть команду на пиво (і ви купуєте).

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

Одна справа, яку я не дуже добре вирішував, це:

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

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

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

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

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

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

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

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

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

• Хакери, Стівен Леві - http://en.wikipedia.org/wiki/Steven_Levy
• Мікросерфи, Дуглас Купланд - http://en.wikipedia.org/wiki/Douglas_Coupland
• Собор і базар, Ерік Реймонд - http://en.wikipedia.org/wiki/Cat Cathedral_and_the_Bazaar

Вони такі ж важливі, як і будь-який типовий спогад про управління (Drucker et al).

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

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

Це може бути через 2 причини.

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

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

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

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

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

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

Утримувати команду щасливою дуже просто

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

Виїзд на команду - хороша ідея (може бути якийсь ігровий план)

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

робіть щомісяця 1: 1 з кожним членом команди, щоб переконатися, що їм комфортно.

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

Будь ласка, дайте мені знати, якщо у вас є додаткові запитання

Я також (французька, так пробачте, мою англійську) менеджер програмного забезпечення, який має науково-технічну освіту, але не спеціально ІТ-програму спочатку. Тому я не маю особливої ​​спорідненості з кодуванням на початку, але я був інженером статистичної якості зі школи Демінга, який має величезну різну викладацьку практику в кожній "сучасній" школі, яка слідувала, хоча вони претендують на спадщину від Демінга. Найгірше - 6 сигм, худне було краще, але, на жаль, сталося це http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

«Спочатку шість сигм було отримано від Toyota Quality Management (TQM) Motorola для досягнення шести рівнів якості сигми, а потім через Allied Signal та GE перетворили на проекти Black Belts на основі статистики, щоб стати програмою зниження витрат - кожен проект потребує чіткої рентабельності інвестицій. Іншими словами, ми заперечували програму від філософії лідерства до ряду разових проектів, щоб зменшити витрати. Це була повна бастардизація оригіналу, і вона рідко призводила до тривалих, стійких змін, тому що не бракувало керівництва та культури.

"Подібна річ трапилася, коли вона зводилася до набору інструментів (наприклад, картографування потокових значень, дошки KPI, комірки, канбан).

"Lean і Six Sigma жодним чином не відображають оригінальне мислення чудових японських компаній або їхніх викладачів, таких як Демінг"

Сьогодні рухливий рух схожий на худий (див. Курс Джеффа Сазерленда та його вшанування Демінга http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), це краще, ніж Водоспад, але воно все ще дуже далеко від оригінального вчення Демінга, тому що замість того, щоб прочитати Демінга в його оригінальному тексті, гуру просто перепаковує його приблизно ніколи не цитуючи цілих 14 принципів управління, та продає інструменти та семінари, які самі по собі мало цінують.

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

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

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

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

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