[mplata 8]

Разработка относительно несложных Embedded проектов от архитектуры до серийного производства (собственные мощности),

 

Что нужно будет делать:

- разработка электрических принципиальных схем;

- разработка топологии;

- трассировка печатных плат;

- программирование микроконтроллеров (STM32, AVR ATMega) разработка низкоуровневого ПО (С, С++);

- запуск, тестирование и отладка опытных образцов изделий;

- разработка КД к разрабатываемым изделиям;

- участие в подготовке проектов к серии.

 

 

Что мы ждём от кандидатов:

- высшее техническое образование в области электроники и электротехники;

- знание ЕСКД

- знание основ электроники, цифровой и аналоговой техники;

- знания современной элементной базы;

- опыт монтажа, регулировки и ремонта электронных устройств;

- знание пакета Altium Designer, PCAD2001+ (архивные проекты);

- навыки быстрого изучения и внедрения интерфейсов (например LoRa, LoRaWAN, Ethernet, USB и пр.)

- английский язык (технический)

- хорошее знание С, С++ (качественный, понятный, чистый код с комментариями)

- опыт работы с RTOS для микроконтроллеров.

- понимание работы процессора и периферии на низком уровне.

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

 

Работа удаленная, но в г. Москва или ближайшей области, так как требуется участие в переговорах и приезды для экспериментов и передачи документации и комплектующих (спаянные платы, компоненты, исполнительные устройства). Работать нужно в СКРАМ системе управления проектами, спринтами по 2 недели в ведением проектов в Битрикс24 под управлением руководителя.

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

Работа по ТК РФ.

На испытательный срок (3мес) оклад чистыми (на руки) 200 000р. После 250 000р. Далее рост в зависимости от успехов. Справки 2НДФЛ для получения кредитов. Ипотека 5-6%.

Токсичных людей нет. Есть у кого что-то спросить, но полноценная школа не предполагается. Ищем человека имеющего опыт. 

[Arcanum 0]

как с вами связаться?

[mplata 8]

1 minute ago, Arcanum said:

как с вами связаться?

можно в личку. 

[dxp 50]

17 часов назад, mplata сказал:

Работать нужно в СКРАМ системе управления проектами, спринтами по 2 недели

Прошу прощения за офтопик, но вот это вот зачем при разработке железа? Это же как-то годится только для очень простых процессов и при разработке вебсайтов, когда нужна постоянная обратная связь с заказчиком/потребителем -- "курс" работы на спринтах и корректируется. При разработке железа нужен свосем другой flow: ТЗ, ведомость исполнения (план-график, роадмап и т.п.), этапность. SCRUM тут вообще не ложится никак и является только помехой.

P.S. Если тема интересна и есть желающие обсудить/высказаться, то может имеет смысл создать отдельную тему.

[mplata 8]

3 hours ago, dxp said:

При разработке железа нужен свосем другой flow: ТЗ, ведомость исполнения (план-график, роадмап и т.п.), этапность. SCRUM тут вообще не ложится никак и является только помехой.

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

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

А так как часто заказчик по ходу разработки меняет или дополняет что то то через этот самый месяц получается катастрофа. 

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

[dxp 50]

40 минут назад, mplata сказал:

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

Это что за ТЗ такое, когда через месяц оказалось, что оно не про то? ТЗ -- серьёзный документ, от него зависит результат чуть не на все 100%. ТЗ -- это отправная точка в разработке. Из него формируются этапы работы. Если через месяц выясняется, что ТЗ не про то, что надо, разработчика ТЗ (или того, кто ему задачу ставил) гнать за профнепригодность.

 

40 минут назад, mplata сказал:

А так как часто заказчик по ходу разработки меняет или дополняет что то то через этот самый месяц получается катастрофа. 

Меняет и дополняет по ходу дела?!!! Серьёзно?! Вот это и корень проблем при использовании IT'шных подходов в разработке железа! Это в софте можно быстро перех..якать, с железом это не прокатывает. Да и с софтом эта практика порочна и является источником массы проблем, просто там последствия ощущаются не так больно. Вместо того, чтобы сразу подумать и спланировать процесс, там доминирует метод "х.як, х..як и в продакшн". Единственный сценарий, где такое оправдано -- это когда задача (что нужно конкретно сделать) недостаточно ясна на старте, и пока не начнёшь, невозможно понять, как конкретно это надо сделать. Поэтому применяется этот метод "тыка" -- сделали что-то, увидели, то или не то. Тут, конечно, нужно всем участвовать -- и заказчику, и разработчику, и периодичность этих контрольных точек должна быть достаточно короткой (1-4 недели) -- те самые спринты. Это как-то работает при разработке софта, но с железом это полный провал. Там нужно всё заранее тщательно проектировать и планировать, потому что перефигачить по ходу дела не получится, т.к. стоимость производства в отличие от софта далеко не ноль.

 

40 минут назад, mplata сказал:

Этого не происходит в скраме, более того все участники знают что происходит на других направлениях

Что знают? Что мешает это знать без скрама? А нужно ли всем участникам это знать? Не будет ли это "знание" отвлекать их от своей конкретной и сложной работы? 

 

40 минут назад, mplata сказал:

когда поступают комплектующие

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

 

40 минут назад, mplata сказал:

когда можно приступать к выпуску КД

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

 

40 минут назад, mplata сказал:

когда нужно отдать корпус в покраску.

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

 

40 минут назад, mplata сказал:

все прозрачно и без нервов

Ну, если потеря кучи времени и отвлечение на посторонние процессы, зачастую искусственные и бесполезные, как натягивание работы на сторипоинты, никого не расстраивает, то пожалуй поверю.  🙂

40 минут назад, mplata сказал:

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

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

 

40 минут назад, mplata сказал:

У нас это прижилось и работает просто великолепно.

Ну, удачи вам

[mplata 8]

Я спорить не буду, каждый выбирает свой метод. 

По поводу ТЗ очень часто заказчик по ходу разработки хочет что-то дополнить. Можно формально поступить: извините этого не было в ТЗ, а можно пойти на встречу. Тут опять каждый решает сам. У нас нет проблем что то добавить, Доп соглашение и вперед. А скрам позволяет безболезненно решить это. 

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

 

[mplata 8]

Кстати нашел хорошую статью о внедрении скрам в Тойота:

https://www.infoq.com/articles/scrum-the-toyota-way/

 

[fpga_student 0]

On 5/14/2024 at 9:28 AM, mplata said:

Я спорить не буду, каждый выбирает свой метод. 

По поводу ТЗ очень часто заказчик по ходу разработки хочет что-то дополнить. Можно формально поступить: извините этого не было в ТЗ, а можно пойти на встречу. Тут опять каждый решает сам. У нас нет проблем что то добавить, Доп соглашение и вперед. А скрам позволяет безболезненно решить это. 

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

Для всех адекватных имхо это приговор. Да и фильтр заказчиков) своеобразный))

 

Наблюдаю в работе креативного человека любителя менять ТЗ на ходу(( Как он вредит своему бизнесу не передать)

[mplata 8]

20 minutes ago, fpga_student said:

Для всех адекватных имхо это приговор. Да и фильтр заказчиков) своеобразный))

 

Наблюдаю в работе креативного человека любителя менять ТЗ на ходу(( Как он вредит своему бизнесу не передать)

Да фильтр, согласен, если ТЗ пересматривается радикально. 

Но я не говорю, что ТЗ полностью поменялось, оно дополнилось, или скорректировалось например из за недоступности компонента (например с рынка РФ ушел Квиктел, а на него изначально ориентировались). А самое главное все прозрачно для всех. Не призываю использовать наш подход, но у нас он прижился и считаю правильным об этом сказать сразу.

[mantech 37]

1 час назад, fpga_student сказал:

Для всех адекватных имхо это приговор. Да и фильтр заказчиков) своеобразный))

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

[mplata 8]

2 minutes ago, mantech said:

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

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

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

А контроль версий это отдельная тема. 

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

[mantech 37]

28 минут назад, mplata сказал:

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

Вот почему обратил на это внимание - "Разработка относительно несложных Embedded проектов "

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

[fpga_student 0]

On 5/16/2024 at 4:01 PM, mantech said:

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

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

 

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

Имхо - без проработанного ТЗ браться за проект это пионерия.

 

[mantech 37]

2 минуты назад, fpga_student сказал:

Имхо - без проработанного ТЗ браться за проект это пионерия.

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