Компания хочет написать собственный инструмент управления проектами, а не использовать сторонний продукт [закрыт]

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

Я думаю, что это пустая трата времени. Есть много отличных инструментов для сторонних разработчиков (например, Axosoft OnTime), которые могут делать все, что нам нужно, и многое другое. Для того, сколько времени разработки нам стоило бы построить собственный модуль управления проектами, мы могли бы купить многочисленные лицензии для стороннего продукта.

Одна из проблем заключается в том, что, хотя мы пишем код для клиента и используя наш собственный модуль управления проектами Intranet, мы обнаруживаем ошибки в модуле, которые нуждаются в исправлении ASAP. Это означает необходимость прекратить работу над кодом клиента, чтобы исправить Интранет. Это просто переводит меня в позвоночник.

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

Что вы, ребята, думаете?

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

EDIT:

Спасибо за отличные ответы, очень ценится. Подведем итог некоторым из них:

Деньги

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

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

Функции

Наличие собственного пользовательского модуля означает отсутствие раздувания - в продукте будут только те функции, которые нам нужны. Моя проблема в том, что есть много бесплатных инструментов управления проектами с открытым исходным кодом, которые уже существуют с минимальными возможностями. Поэтому, даже если стоимость является проблемой, мы можем заглянуть в open-source. Опять же все сводится к тому, что я не вижу смысла писать инструмент управления проектами в наши дни. Это немного похоже на создание собственного веб-браузера - почему ?, в чем смысл?

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

В конце концов разработчики пишут код, это разработчики, которые делают деньги для бизнеса. Таким образом, насколько мне известно, разработчики играют очень большую роль в определении того, как компания должна управлять проектами и какие инструменты используются. «Я спартан, арх!» :)

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

Edit:

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

Но он не был убежден. Un-е @ король-правдоподобно! : (

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

EDIT:

Отвечая на недавние комментарии:

1) Разработчик, который говорит, что он «не может быть обеспокоен».

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

Конечным результатом было то, что мы создали модуль управления, написанный в ASP.NET MVC разработчиком с минимальным опытом MVC (я мог только предоставить небольшой кусок времени этому модулю, так как я был полный рабочий день на большой клиентский проект). Было бы несправедливо сказать, что это было довольно дерьмо (без вины дев). Так что да, я не стыжусь сказать, что я не мог потрудиться, чтобы разделить мое время на создание бессмысленного модуля управления, пытаясь также написать систему для клиента, который на самом деле собирался заплатить нам.

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

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

3) Тот, кого все уже набрали, диктаторское управление.

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

EDIT:

Чтобы представить больше контекста ситуации в то время - наш босс хотел, чтобы мы одновременно писали клиентское приложение и модуль управления. Они также хотели, чтобы мы фактически использовали модуль управления (рассказы пользователей, задачи и т. Д.), В то время как он строился, то есть корм для собак, с задачами, связанными с проектом клиента.

Представьте себе создание TFS и разработку новой версии Visual Studio, но используя встроенную TFS для хранения ваших рабочих элементов, рассказов пользователей, заметок и т. д., связанных с проектом разработки Visual Studio. Не круто.

6 голосов | спросил Jason Evans 25 J0000006Europe/Moscow 2011, 13:22:48

13 ответов


14

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

Конечно, это похоже на пустую трату времени, и, вероятно, это так, но установка, настройка и привыкание к стороннему инструменту также занимает некоторое время.

Мое отношение к ситуации: если руководство этого хочет, сделайте это. Это их обязанность решить, или не стоит усилий.

ответил user281377 25 J0000006Europe/Moscow 2011, 13:31:30
12

Хорошо, может быть, я просто параноик, но это может быть немного читать письмо на стене.

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

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

Если у них нет проблемы с денежным потоком, то:

  1. Хозяин хочет положить перо в шляпу с этим проектом. Говорить ему, что это будет огромная НЕИСПРАВНОСТЬ, заставит вас выглядеть так, как вы не можете доставить.
  2. У босса нет понятия о разработке программного обеспечения, поэтому он рассчитывает продать этот инструмент, как и клиентам.
  3. Это маркетинг. Я работал в магазине, где у нас был такой инструмент. Разработчику потребовался полный рабочий день, чтобы он работал и добавлял функции. В основном 100 тыс. Долл. США в стоимостном /годном размере. Но они должны были требовать и хвастаться этим дерьмом всем своим клиентам. (Это был дерьмо, но это был наш дерьмо, он работал вроде как).
  4. Вы управляете руководителем и менеджером (неправильно), что ваш процесс является настолько особенным и уникальным, что не может работать рабочий инструмент полки.

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

ответил Bill Leeper 15 MarpmThu, 15 Mar 2012 18:35:06 +04002012-03-15T18:35:06+04:0006 2012, 18:35:06
6

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

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

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

ответил wolfgangsz 25 J0000006Europe/Moscow 2011, 15:05:25
3

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

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

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

Меня интересует Agile, а также UML. От вашего отношения, я бы догадался, что вы не в пользу UML или разработки, основанной на характеристиках. Если бы вы были, вам могло бы показаться, что вид управления в высшей степени разумный и достижимый при правильном процессе.

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

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

Зачем платить за одну функцию, которая вам не нужна, что не отражает ваш бизнес?

Мое предложение:

  • чтобы ваши начальники считали, что интрасеть потребует инвестиций, чтобы стать коммерчески жизнеспособной;
  • рассмотрите восстановление интрасети как часть требования предоставления функций PM; затем
  • Проворное все, что это за твоя работа; но, прежде всего
  • перестаньте сулить и ныть! Ваша негативность - это не то, за что вы платите. Им платят за управление, а не за вас.

Они управляют, вы гремете.

ответил DVious 8 Maypm12 2012, 15:31:57
2

Если боссы не нуждаются в пользовательских функциях, которые недоступны в продукте с открытым исходным кодом /сторонней стороной, я бы сказал, что это полная трата времени.

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

ответил stuartmclark 25 J0000006Europe/Moscow 2011, 13:29:04
2

Ваш босс либо заботится о расходах, либо отвечает тем, кто это делает. Вам нужно сделать свое дело с точки зрения часов и долларов. Согласитесь с ним по общей оценке шара за часы работы, добавьте дополнительное время для исправлений и поддержки и умножьте его на обычную почасовую заработную плату в вашей компании плюс накладные расходы (для обычной софтверной компании - 50-100 долларов США за час разработчика примерно соответствует полному).

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

E.G. . Написание пользовательского инструмента займет около 800 часов разработчика (это 10 недель разработки или около 5 недель для 4 разработчиков, что не является незначительным, но не является огромным проектом). Теперь умножьте это на 75 долларов США (наша гипотетическая общая стоимость в час на разработчика, включая накладные расходы). Это теперь проект стоимостью 60 000 долларов для вашей компании. Теперь вы найдете потрясающий инструмент онлайн за 1000 долларов США /место, и у вас в общей сложности 10 разработчиков в вашей компании. Теперь стороннее приложение готово, гарантировано, будет стабильным и полностью поддерживаемым, и, что самое главное, вашему боссу, стоит 1/6 от цены за прокачку его самостоятельно.

ответил Greg Jackson 25 J0000006Europe/Moscow 2011, 13:35:01
2

Я использовал Trac, Trello, Pivotal Tracker и другие, и я бы использовал Pivotal Tracker.

Я бы посоветовал снова поговорить с вашим боссом со словами, похожими на:

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

Я хочу, чтобы компания преуспела, и я хочу, чтобы мы оба добились успеха.

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

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

ответил Michael Durrant 15 MarpmThu, 15 Mar 2012 17:15:41 +04002012-03-15T17:15:41+04:0005 2012, 17:15:41
1

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

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

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

Хорошее решение - возьмите продукт, который очень расширяемый и настраиваемый. Наиболее успешными являются коммерческие и с открытым исходным кодом. Вы можете настроить Trac , Redmine , Основной трекер или даже JIRA , чтобы точно удовлетворить ваши потребности. Есть также тонны плагинов, поэтому очень вероятно, что вы сможете приблизиться к тому, что вам нужно, не написав ни одной строки кода.

ответил vartec 15 MarpmThu, 15 Mar 2012 17:07:00 +04002012-03-15T17:07:00+04:0005 2012, 17:07:00
0

Почему бы не взять средний план и не начать с чего-то вроде Trac (http://trac.edgewall.org/), а затем настроить его? Если у вас есть парень, который хорош с python, то работа может идти довольно быстро. У этого есть хороший дизайн, который облегчает работу. Это было бы хорошей отправной точкой для всего, что вы хотите сделать, с большим количеством работы, уже движущей к вашим гибким целям развития, и вы можете дать ей внутреннюю любовь, которая сделает ее вашей.

Кстати, если у вас есть навыки Perl внутри, вы можете начать с Request Tracker (http://bestpractical.com/rt/) и получить хорошее конечное состояние.

ответил unclejamil 25 J0000006Europe/Moscow 2011, 23:05:15
0

Я собираюсь ответить немного иначе, чем все остальные.

Я думаю, что может упасть до культуры компании и /или политики .

Как заявили другие, Плюсы этого дела:

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

И недостатки в этом:

  • Трудно для пользователей забрать новые инструменты PM
  • Другие инструменты PM могут оказаться непригодными для вашей компании.
  • Более высокие затраты (как вы заявили)

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

Корпоративная культура может не заботиться ни о какой из этих вещей . Они, возможно, не захотят исследовать или использовать другие уже доступные инструменты PM. Например, если это магазин Microsoft, где каждое программное обеспечение должно быть более или менее получено от Microsoft. Рассмотрение чего-либо еще не дано.

Возможно, уровень политики может вступить в игру . Некоторые менеджеры хотят руководить инициативами, когда они управляют командой, которая строит this , экономит компанию x amount и т. Д. Просто используя инструмент другого поставщика, не будет выделяться способность руководства к хорошо, управляйте.

Опять же, это всего лишь предложения по возможности сценариев

ответил spong 26 J0000006Europe/Moscow 2011, 00:36:40
0

Работая в одном месте, где мы заменили компанию, разработали инструмент управления проектами bare bones с многофункциональным настраиваемым инструментом. Я бы вернулся к надежной, легко поддерживаемой компании, разработанной инструментом в одно мгновение. Стоимость добавления нескольких новых функций, которые нам нужны, когда мы менялись, значительно перевешивалась временем, потраченным ежедневно, пытаясь заставить этот инструмент работать для нашей компании (для закрытия проекта, например, может потребоваться до половины часа, чем за 30 секунд до этого), а также огромную сумму денег, которую она стоила, а также тысячи долларов в развитии клиентов, которые нам нужно было заплатить, чтобы переделать эту штуку, чтобы она была более удобной для пользователя.

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

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

ответил HLGEM 15 MarpmThu, 15 Mar 2012 18:15:11 +04002012-03-15T18:15:11+04:0006 2012, 18:15:11
0

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

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

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

ответил JeffO 8 Maypm12 2012, 16:21:21
0

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

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

По крайней мере, когда вы будете обсуждать спецификации, попытайтесь ограничить возможности, которые вам придется реализовать до строгого минимума . Игнорируйте тот факт, что может продавать продукт клиентам в будущем: скорее всего, клиентов не будет. Таким образом, вы сократите потери и, возможно, закончите с программой, которая имеет только те функции, которые вам нужны.

ответил Dmitry Grigoryev 6 MarpmTue, 06 Mar 2018 17:43:32 +03002018-03-06T17:43:32+03:0005 2018, 17:43:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132