Що програмісти повинні знати про бізнес / управління? [зачинено]

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

Який найменший мінімум, який повинні знати усі розробники про управління проектами / бізнес?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Питання типу:

• який процес подання пропозицій у компанії?
• як ми взяли участь?
• як ми плануємо оплатити клієнта?

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

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

Який найменший мінімум, який повинні знати усі розробники про управління проектами / бізнес?

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

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

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

Який найменший мінімум, який повинні знати усі розробники про управління проектами / бізнес?

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

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

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

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

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

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

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

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

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

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

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