Уверяю вас, на самом деле вы этого не знаете. Если повезет, потребности можно угадать, ну, может, в одном случае из десяти. В остальных девяти вы будете понапрасну тратить силы и усложнять систему в попытках приспособить под будущее то, что либо претерпит изменения, либо вообще не пригодится.
Хочу обсудить данное высказывание в целом и дополнить статью (как оригинальную, так и перевод), чтобы она была более полной, так как я не совсем согласен с высказыванием в том виде, в котором оно написано.
В первую очередь, каждый член команды - от руководителя, менеджера до разработчика, сотрудника отдела кадров и т.д. это часть компании. Каждый из них делает свою работу и приводит компанию тем или иным образом к успеху. Нельзя сказать, что кто-то лучше, а кто-то хуже.
Если экстраполировать данную мысль на статью, то "диктатура бизнеса" и "бизнес точно знает как делать деньги" это ложь. В первую очередь, все мы - люди. В первую очередь, важно человеческое отношение ко всем внутри всех отделов и между отделами. В первую очередь, важна хорошо выстроенная коммуникация и полное понимание и уважение между коллегами.
Каждый разработчик имеет полное право предложить пути и способы улучшения бизнес процессов, идеи по увеличению прибыли, идеи по улучшению корпоративной культуры и улучшения имиджа компании. Открытость к идеям - это ключ к росту бизнеса.
Следующий момент заключается в том, что я безусловно согласен с тем, что "тайное добавление кода на будущее" это плохо. Не стоит пытаться единолично сформировать решение всех проблем компании и закрыть все возможные исключительные случаи и создать систему, которая будет работать при любых входных данных - это не эффективный подход. Аналогично, эту мысль мы можем экстраполировать и на Бизнес, он не может принимать эффективные решения самостоятельно, он не может знать как создать продукт, который через год-два не станет не поддерживаемым камнем, добавление новых фич в который будет невозможно. Из этого, мы делаем вывод, что основа успешного бизнеса - это коммуникация. Бизнес хорошо понимает, чего бы хотел конечный пользователь от продукта в данный момент, а IT-отдел хорошо понимает как создать продукт, который будет работать, масштабироваться и будет легок в поддержке. Ключ здесь в том, чтобы бизнес был заинтересован в том, чтобы его продукт не сыпался от багов и каждая новая фича не создавала очередную волну нагрузки на Техническую поддержку и Отдел по работе с клиентами, а IT-отдел должен бережно относиться к тем средствам, которые, безусловно, затрачиваются на разработку.
Подводя итог последней мысли - нужно чтобы каждый четко понимал текущие цели и ключевые метрики по каждой фиче, компоненту, модулю, проекту в целом. При "диктатуре бизнеса" вы рискуете прийти к тому, что ваш разработчик и IT-отдел это набор "болванчиков", которые даже не понимают зачем были выпущены все те фичи, которые они разработали за последние месяцы-полгода-год.
Выводы которые хотелось бы здесь сделать: 1) Не тратьте деньги бизнеса понапрасну, то есть не пытайтесь принимать решения в одиночку. Вы - команда, проект - коллектив. Всегда нужно выносить свои идеи на обсуждения более чем с 1 человеком и, желательно, более чем из одного отдела (это, кстати, работает не только на проекте, но и в жизни в целом). 2) Не создавайте "культ бизнеса" и "культ все вокруг тупые, а я умный" (применимо ко всем сторонам конфликта). Помните о том, что каждый из нас в первую очередь человек, а не бог или гений, отдельно взятый человек может многое, но может и во многом ошибаться. 3) Объединяя первые два пункта - важен баланс, никогда не стоит фокусироваться либо только на бизнесе, либо только на Технической части. Важны все компоненты и все члены команды. Фокусируйтесь на эффективном управлении, эффективной коммуникации и работе над проблемами внутри компании.
Спасибо!
Information
Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity
Specialization
Бэкенд разработчик, Архитектор программного обеспечения
Уверяю вас, на самом деле вы этого не знаете. Если повезет, потребности можно угадать, ну, может, в одном случае из десяти. В остальных девяти вы будете понапрасну тратить силы и усложнять систему в попытках приспособить под будущее то, что либо претерпит изменения, либо вообще не пригодится.
Хочу обсудить данное высказывание в целом и дополнить статью (как оригинальную, так и перевод), чтобы она была более полной, так как я не совсем согласен с высказыванием в том виде, в котором оно написано.
В первую очередь, каждый член команды - от руководителя, менеджера до разработчика, сотрудника отдела кадров и т.д. это часть компании. Каждый из них делает свою работу и приводит компанию тем или иным образом к успеху. Нельзя сказать, что кто-то лучше, а кто-то хуже.
Если экстраполировать данную мысль на статью, то "диктатура бизнеса" и "бизнес точно знает как делать деньги" это ложь. В первую очередь, все мы - люди. В первую очередь, важно человеческое отношение ко всем внутри всех отделов и между отделами. В первую очередь, важна хорошо выстроенная коммуникация и полное понимание и уважение между коллегами.
Каждый разработчик имеет полное право предложить пути и способы улучшения бизнес процессов, идеи по увеличению прибыли, идеи по улучшению корпоративной культуры и улучшения имиджа компании. Открытость к идеям - это ключ к росту бизнеса.
Следующий момент заключается в том, что я безусловно согласен с тем, что "тайное добавление кода на будущее" это плохо. Не стоит пытаться единолично сформировать решение всех проблем компании и закрыть все возможные исключительные случаи и создать систему, которая будет работать при любых входных данных - это не эффективный подход.
Аналогично, эту мысль мы можем экстраполировать и на Бизнес, он не может принимать эффективные решения самостоятельно, он не может знать как создать продукт, который через год-два не станет не поддерживаемым камнем, добавление новых фич в который будет невозможно.
Из этого, мы делаем вывод, что основа успешного бизнеса - это коммуникация. Бизнес хорошо понимает, чего бы хотел конечный пользователь от продукта в данный момент, а IT-отдел хорошо понимает как создать продукт, который будет работать, масштабироваться и будет легок в поддержке. Ключ здесь в том, чтобы бизнес был заинтересован в том, чтобы его продукт не сыпался от багов и каждая новая фича не создавала очередную волну нагрузки на Техническую поддержку и Отдел по работе с клиентами, а IT-отдел должен бережно относиться к тем средствам, которые, безусловно, затрачиваются на разработку.
Подводя итог последней мысли - нужно чтобы каждый четко понимал текущие цели и ключевые метрики по каждой фиче, компоненту, модулю, проекту в целом. При "диктатуре бизнеса" вы рискуете прийти к тому, что ваш разработчик и IT-отдел это набор "болванчиков", которые даже не понимают зачем были выпущены все те фичи, которые они разработали за последние месяцы-полгода-год.
Выводы которые хотелось бы здесь сделать:
1) Не тратьте деньги бизнеса понапрасну, то есть не пытайтесь принимать решения в одиночку. Вы - команда, проект - коллектив. Всегда нужно выносить свои идеи на обсуждения более чем с 1 человеком и, желательно, более чем из одного отдела (это, кстати, работает не только на проекте, но и в жизни в целом).
2) Не создавайте "культ бизнеса" и "культ все вокруг тупые, а я умный" (применимо ко всем сторонам конфликта). Помните о том, что каждый из нас в первую очередь человек, а не бог или гений, отдельно взятый человек может многое, но может и во многом ошибаться.
3) Объединяя первые два пункта - важен баланс, никогда не стоит фокусироваться либо только на бизнесе, либо только на Технической части. Важны все компоненты и все члены команды. Фокусируйтесь на эффективном управлении, эффективной коммуникации и работе над проблемами внутри компании.
Спасибо!