Перейти к содержанию
    

Помогите подобрать комплекс для организации совместной работы инженеров/программистов

Доброго времени суток.

 

Прошу помощи, вероятно кто-то сталкивался с похожим вопросом

 

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

 

Требуется: установить некий комплект программ на выделенном сервере для организации совместной работы.

- Система контроля версий

- файловый сервер (желательно что-то типа облака) с контролем уровня доступа к конкретным папка/файлам, ну или просто ФТП

- раздача заданий, контроль их выполнения, ведение истории

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

- отражение переключение работника между долгосрочными и текущими задачами, дабы примерно оценить сроки работы над каждым

- вики или типа того для составления мини-инструкция для выполнения конкретных задач

- онлайн мессенджер

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

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

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

- очень желательно юзабилити, лезть в дебри с установкой и настройкой некогда, да и не сильно хочется (но что такое Апач, SQL server и т.д. представление имею, так что не все потеряно )

 

Ну и желательно free или cracked.

 

Заранее благодарен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для железячников мало, чего есть, но мы, например, используем Atlassian Confluence/Jira + Subversion - она платная, но достаточно легкая в установке и освоении.

 

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

Wiki - нафига, если есть Word?

 

Раздача заданий/контроль их выполнения - это вообще против мотивации - кому надо, чтобы его теперь менеджер еще и через интернет подгонял?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

..программы - это, конечно, очень важно..) но для успешного управления...важно понимание психологии людей.....[/url] ;)

 

психология - это одно из многих... или скажем так - это составляющая, но не единственная вещь.

 

статья, извините не об чём.

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

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

мнение всей команды и каждого в отдельности - очень и очень ценно. Или Вы считаете, что самый главный=самый умный? :) (типичное заблуждение).

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

 

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

не только поставленные задачи, но и полученные вспомогательные бонусы. Как пример: приём сотрудника на работу. Казалось бы - и что тут за задача?

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

2) быстрое вхождение в коллектив нового человека(через пару часов они уже общаются на равных в курилке, через сутки все знают о человеке,

человек знает кто-чем дышит) 3) объективная оценка сильных и слабых сторон нового человека 4) стимуляция всего коллектива на познание нового и

глубокий апгрэйд накопленной тех. инфы 5) минимально потраченное время (несколько часов) 6) получение всеми участниками положительных эмоций

от процесса.

 

удачи вам

(круглый)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

раздача заданий, контроль их выполнения

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

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

 

Работают в нем по большей части инженеры-электронщики-разработчики...

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

 

Сделать и разработать - это две большие разницы. Сделать - это производство: у вас есть комплект КД с технологическим описанием, там сказано 3 землекопа делают 10 приборов за неделю. Нужно 100 - или 30 человек или 10 недель.

Разработка - вопрос творческий. Даже сроки в разводке, когда уже есть и схема, и элементы извесны - это просто прогноз основанный на предыдущих подобных разводках. Он точен когда в 6U вместо 2 RS485 надо развести 2 CAN и сильно зависит от исполнителя, если вы на плате iPhone замените процессор на TI/mali... А как оценить сроки собственной реализации модема, вокодера..?

 

Система контроля версий,файловый сервер

 

Понимаете ли вы, что с введением этой системы вся ответственность за сохранность исходников/чертежей/РЭ/ТУ снимается с исполнителя и целиком лежит на фирме/сисадмине?

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

 

Не заставят ли в итоге разработчика сменить LTspice на другое ПО, более совместимое с SVN, несмотря на отсутвие в нём нужных элементов и работающем на одном ядре? То же касается компиляторов, разводчиков плат и т.д.?

 

отражение переключение работника между долгосрочными и текущими задачами

 

В днях или часах? Конкретный пример: весь декабрь я занимался оптимизацией источника питания путём моделирования в LTspice. Т.е. приходя на работу - запускал моделирование, и компьютер 8 часов грузя процессор 100% рассчитывал 150мС переходных процессов сохраняя результат в 40ГБ файл. В конце дня я несколько минут анализировал результат и принимал решения о том, какой вариант моделировать завтра.

Параллельно мной велась оптимизация алгоритма для МК по критерию скорости и используемой памяти.

 

Какие данные надо заносить в базу, чтобы она отразила: затрачено - 2чч(оплата), срок - 23чд(цена), возможность совмещения сроков с другими вычислительно незатратными проектами?

 

Как быть в ситуации, когда Matlab обрабатывает данные разными способами для выбора из них оптимального, а ты в это время с паяльником и осциллографом проверяешь работоспособность плат с DSP пришедших из монтажа, на которых в последствии будет реализован этот оптимальный алгоритм?

 

Выдадут ли мне премию и лишат ли премии начальника отдела, за то, что на остальных рабочих местах оснащённых i5 люди работали только в ворде/калькуляторе? :)

 

с контролем уровня доступа

Разработчик сможет запретить просмотр части файлов менеджеру? Объясню почему:

 

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

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

 

Не захочет ли менеджер понять, зачем я 23 дня менял номиналы при незначительном изменении схемы, и не покажется ли ему этот процесс долгим и неэффективным? Не начнёт ли он ставить палки в колёса разработчику через неделю?

 

онлайн мессенджер

Должен ли разработчик реагировать на сообщения в нём или не дай бог в чате? Представьте, я программист, в голове сложилось красивое решение алгоритма 1 с кучей внешних связей, я его пытаюсь описять в рамках языка компилятору... и тут - тадам рассылка: "все задействованные в алгоритме 2 - он должен работать и на ХР", и такая хрень каждую минуту!!! Я в особых случаях даже телефон сам не беру...

 

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

 

Т.е. рабочее место, после введения сервиса, должно быть под виндой10х64 и в корпоративной сети всё моё рабочее время?

А если надо проверить прибор генерящий широковещательно 10000 пакетов в секунду - в корпоративной сети 1C не ляжет?

А если надо проверить прибор под ХР32/QNX/Vista - и я выду из сети - менеджер не обидется, что я не читаю чат?

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

 

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

 

Этот пункт вообще не возможен. Пробовали. Даже тупой листик рядом с кассой элементов в который каждый заносил, что он взял - просуществовал в адекватном виде до первого аврала перед сдачей. А неадекватный - он не нужен.

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

 

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

Опять же как отчитываться за использованное? Монтаж понятно, но есть и ремонт при наладке...

Вот у нас недавно, пришел начальник, взял дорогой и редкий элемент в руки - мы говорим: "осторожно хрупкий", "ага" - сказал он и сломал!!!

Мне что в вашу систему писать: "сломал такой-то начальник т.к. руки из ж"? А какие орг выводы будут: начальника заменят или потребуют исключить элемент из разработок?

 

PS: хотелось бы услышать от Кристина_088 зачем она подняла тему 2013 года, и от Марик - как он решил свою задачу и доволен ли решением...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

PS: хотелось бы услышать от Кристина_088 зачем она подняла тему 2013 года

Для рекламы, зачем же ещё (ссылка в сообщении).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

все эти программы - это, конечно, очень важно..) но для успешного управления проектами очень важно понимание психологии людей..непонятно, почему в этом отделе форума нет таких тем.. но если кто заинтересуется - очень опытный PM делится своим опытом тут ;)
Эта ссылка на досужие вымыслы молодого РМ, недавно получившего должность. По своему опыту РМ разного уровня с более чем 30-ти летним стажем - все гораздо прозаичнее и жестче. Да и ходить кипятком по поводу "придумки" командира не имеет смысла. В реальной жизни всякий обман, даже с благой (как это кажется руководителю) целью вскроется позже и оставит глубокие раны (деморализует) у коллектива. Я это наблюдал много раз.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Раз уж подняли тему, отпишусь и о своём опыте со стороны "играющего тренера" - разработчика и руководителя небольшого коллектива разработчиков.. :biggrin:

 

Используем Redmine для постановки, обсуждения и контроля задач. Для контроля версий - SVN.

 

Приведу, что стало проще на конкретных примерах:

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

 

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

 

После изготовления платы начинается процесс отладки. Все выявленные замечания опять же заносятся в эту тему. Опять же, удобно, что всё в одном месте. Раньше каждый исполнитель (схемотехник, конструктор и т.д.) записывал у себя свои косяки на бумажке. Потом надо было собраться, объединить все эти замечания, постараться ничего не забыть. Здесь же к моменту, когда первые образцы прошли все испытания, уже готов лог требуемых изменений. Достаточно аккуратно их внести.

 

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

 

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

 

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

 

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

Опять же как отчитываться за использованное? Монтаж понятно, но есть и ремонт при наладке...

Элементарно это реализуется. В наших реалиях через общую 1С базу. У буржуев свои PLM-системы. Как отчитываться? Да списывается на ремонт, отладку, эксперименты (нужное подчеркнуть). Как и на любом складе.

 

Без обид, Вы воспринимаете руководителя (PM и т.д.) как тупого надсмотрщика в пробковом шлеме и с бамбуковой палкой. Который в электронике ни черта не смыслит. И единственное, что делает - контролирует сроки и отчитывается перед вышестоящим начальством. Если это так, то надо не систему управления внедрять, а работу менять. :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Элементарно это реализуется. В наших реалиях через общую 1С базу.

Это если она есть - общая 1С. Нам не смогли дать доступа к складской базе, даже RO, даже на одну машину. По моему на складе нет сети, а у снабженцев есть только база заказов. И нет на предприятии человека, чтоб поставил хоть на один комп в отдел эту базу, пусть даже снапшот её. :(

 

Без обид, Вы воспринимаете руководителя (PM и т.д.) как тупого надсмотрщика в пробковом шлеме и с бамбуковой палкой. Который в электронике ни черта не смыслит. И единственное, что делает - контролирует сроки и отчитывается перед вышестоящим начальством. Если это так, то надо не систему управления внедрять, а работу менять. :rolleyes:

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

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

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

 

Не уверен про пробковый шлем, но вариант про завышенное ЧСВ PM я приводил.

 

Для рекламы, зачем же ещё (ссылка в сообщении).

Эх, старый я стал - повёлся, переходил туда читать...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

И если уровень компетенции управленцев и разработчиков не позволяет это понять, то никаким софтом проблему не решить.

 

Но иногда "верхи" просто не понимают необходимости и важности некоторых вещей (как с вашим примером с 1С). Перефразируя тов. Мичурина: объяснить им это - вот наша задача. :biggrin:

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Без обид, Вы воспринимаете руководителя (PM и т.д.) как тупого надсмотрщика в пробковом шлеме и с бамбуковой палкой. Который в электронике ни черта не смыслит. И единственное, что делает - контролирует сроки и отчитывается перед вышестоящим начальством. Если это так, то надо не систему управления внедрять, а работу менять. :rolleyes:

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

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

 

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

Нихрена оно не поубавилось.

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

PM и технический лидер - это два разных человека.

 

Так какие проблемы? Речь же шла о том, что разрабом руководит PM, который в этом ни черта не понимает. А в вашей структуре: разработчики контролируется техлидом, а техлид(ы) отвечает перед PM-ом, PM разруливает вопросы с руководством и заказчиком. Каждый занят делом и все довольны.

 

А в наших реалиях, да. Все эти роли плавающие и часто исполняются одним человеком. :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

При том что изначально ориентирую новых сотрудников на самостоятельную работу.

Решения этой проблемы пока не нашел. Такое впечатление что "лень думать" в принципе не лечится.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Серебряной пули нет.

Я перепробывал сотни программ.

В результате остановился на примитивной Beyound Compare и сравнение "что было" и "что стало".

Уже лет 5 так работаю.

 

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

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

При том что изначально ориентирую новых сотрудников на самостоятельную работу.

Решения этой проблемы пока не нашел. Такое впечатление что "лень думать" в принципе не лечится.

Тут дело в чувстве собственного достоинства.

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

Поэтому я спрашивал только тогда когда перелопатил всю библиотеку но так и не смог разобраться.

А есть люди которым палец о палец сложно ударить. Им проще 100 раз переспросить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...