Что программисты должны знать о бизнесе / управлении? [закрыто]

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

Какой минимум должен знать каждый разработчик для управления проектами / бизнесом, чтобы функционировать?

Я думаю, вам нужно понять, как ваша компания зарабатывает деньги. Вы также должны уметь оценивать, следует ли вам что-то делать, чтобы заработать больше денег, то есть лучше выполнять свою работу. Самое важное, что это означает, что вам нужно уметь определить, на какую задачу вы работаете, над чем следует приложить больше всего усилий, и как расставить приоритеты для поставленных вами задач.

Кроме того, программисты должны понимать, что, хотя технически что-то может быть лучшим выбором, этот выбор не может быть лучшим выбором для бизнеса. И это хорошая причина, чтобы не идти технически лучшим путем.

Знание бизнеса и менеджмента - и маркетинга - конечно, не повредит. Это действительно зависит от контекста, в котором вы работаете.

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

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

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

По крайней мере, вы должны глубоко понимать, что ваша зарплата не просто автоматически приходит откуда-то. Вам не платят за сидение и кодирование. Успех продаж и взаимоотношений с клиентами делает или разрушает успех вашей компании (и в конечном итоге вашей). Вот откуда деньги.

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

Знание и принятие этой сути ведения бизнеса - важная вещь. Даже если вы не особенно интересуетесь бизнесом (я не интересуюсь), вы просто не можете игнорировать его как «дело белых воротничков», если вы сами заинтересованы в получении оплаты. ИМХО, технические детали и словарь бизнеса / менеджмента не так важны, хотя изучение некоторых основ определенно не повредит.

Не желая быть злым, но я бы сказал, что «им нужно знать, чтобы оставить это в руках людей, чья работа это». Как бы это ни звучало как ересь, ты не можешь знать все.

Но, да, нужно знать некоторые минимумы, некоторые основы экономики. Итак, скажем, основы микроэкономики (микроэкономика <- экономика, которая имеет дело с небольшой системой, скажем, компанией), некоторые базовые экономические теории (инфляция для вас хорошая или плохая? Как это влияет на другие факторы?), Некоторые основы того, как работает социальная система (если вы находитесь в стране, которая организована таким образом), основы торговли облигациями (если вы находитесь в компании, которая организована в этом путь) ...

Однако, если я неправильно понял ваш вопрос, и вы спрашиваете, что является предложением или предложением ... это лучше объяснить в википедии. Тем не менее, правила, касающиеся их, являются скорее юридической темой, чем экономической.

но когда мой менеджер проекта начинает говорить о том, как мы выиграли новый контракт, или мы участвуем в новой заявке, или ... что-нибудь бизнес, а не техническое, на самом деле ... я могу потеряться довольно быстро.

Чтобы узнать больше о бизнесе, нужно только принять участие. Совещание может быть не лучшим форумом для обсуждения определенных вопросов, но наиболее определенно после таких встреч попросите своего менеджера рассказать о предложении или о связанных с бизнесом вещах, которые вы потеряли.

Такие вопросы, как,

• что такое процесс предложения в компании?
• как мы ввязались?
• как мы планируем выставлять счета клиенту?

Каждый из вышеперечисленных является маленькими показателями того, как работает ваша компания. Это приближает вас к внутренним и внутренним работам, чтобы хотя бы знать, как бизнес зарабатывает деньги. Я думаю, что главное здесь - спросить о том, чего вы не знаете!

Кроме того, «я могу потеряться довольно быстро» либо означает для меня, вы дерьмо, или вы действительно не знаете. Ваше отношение может иметь значение, если вы хотите узнать больше об этом.

Какой минимум должен знать каждый разработчик для управления проектами / бизнесом, чтобы функционировать?

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

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

Общий совет - изучайте / практикуйте / улучшайте другие менее технические навыки в начале вашей карьеры, поскольку это будет полезно в последующие годы (если, конечно, вы все еще не решите )

Какой минимум должен знать каждый разработчик для управления проектами / бизнесом, чтобы функционировать?

«... хорошая технология - это только 10% успеха. Если ваше руководство не знает, как управлять успешным инженерным проектом, или ваш отдел маркетинга не знает, как получить доступ к клиентам, или не говорит вам, что клиент хочет, или если ваши юристы неправильно обрабатывают вашу интеллектуальную собственность, или если главный архитектор не имеет возможности создать последовательную и простую архитектуру, то ваша работа может быть напрасной, и вы можете потратить годы на создание вещей что никогда не увидит свет ". ( Вещи, которые я хотел бы узнать в инженерной школе ... )

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

Минимум зависит от компании. Я работал в месте, где за разработку программы отвечали другие люди, и мне пришлось переводить подробные спецификации на COBOL. Это действительно не очень весело, но мне сначала не нужно было ничего знать о бизнесе.

Как только вы начинаете высказываться по поводу разработки программы (или, желательно, если вы начинаете там), вам нужно знать, что делает бизнес, чтобы вы могли понять, что на самом деле нужно вашим пользователям. Знание большего о бизнесе означает, что люди должны рассказывать вам вещи менее подробно, поэтому ваша ценность для бизнеса возрастает. Иногда вы можете делать что-то по собственной инициативе, что поможет бизнесу, а также повысит вашу ценность. Это часто отражается в вашей должности и зарплате.

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

Это также может помочь, если вы знаете, что деловые отношения значат для вас, как новый контракт влияет на вас.

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

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

Есть некоторые основы финансового состояния, которые я бы рассмотрел, например, понимание того, где находится ваша компания с точки зрения зрелости: это стартап, который до сих пор сжигает деньги инвесторов-ангелов или деньги венчурных капиталистов сейчас? Насколько близка к прибыльности компания? Существуют ли какие-либо серьезные судебные процессы, которые могут убить компанию в ближайшем будущем?

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

Если вы хотите получить больше информации о бизнесе, вы можете запросить более подробную информацию о контракте, который был выигран. Сколько единиц продается? Это начальный пилотный проект у клиента или сейчас массовое внедрение? Те базовые вопросы, которые могут помочь, дают немного больше подробностей о том, что вам, в конечном итоге, придется решать дальше. Например, если ваша компания начала получать массовые заказы, не может ли это привести к тому, что некоторые системы будут доведены до предела, который может потребоваться исправить как можно скорее, нет? Хотя я привел некоторые туманные области и лишь несколько конкретных примеров, это те части, которые я склонен замечать в компании. То, насколько бюрократическим является HR, было бы еще одним фактором, который нельзя забывать здесь до некоторой степени.