И в таких классах задач можно «договориться на берегу», просто требования к разработчику и его действиям (или говоря языком статьи нормы входа, деятельности) будут другие (выше) нежели к разрабу, работающего в более комфортных условиях. Меняются приоритеты/требования — короткие спринты/задачи, бьем задачи на элементарные (можно сделать в течение 1-2 дней, когда приоритеты не меняются). Перед началом разработки — поговорить с заказчиком, убедиться, что все понял правильно. Постоянно показывать результат, не изобретать велосипеды, не тупить над проблемой оптимизации сортировки гномиков и пр. Статья правильная и простая как 2х2 — четыре
Мне одному кажется, что прилетел капитан очевидность? Понятно же, что для определения проблем в чем-либо для начала неплохо бы определить понятие нормы или нормальности.
Мозгоправы в большинстве своем в России специализируются на лечении зависимостей, прежде всего алкогольной. Всякие проблемы менеджеров с зарплатой 5000+ они воспринимают исключительно как "с жиру беситесь". Наверное есть хорошие, но где их найти. Да и тратить свое время на сомнительные сеансы не очень хочется — время не бесконечно
Готов взять на работу программистов без UML, бинарных деревьев и прочей фигни. Сайтик, формочка и вперед (С#, Js, Angular, немного Oracle).
Денег 150+ :)
Хочу статью «9 причин, почему вы все еще тим лид». Первые пункты:
1. Потому что Вы можете заставить работать то, что еще вчера даже не компилилось
2. Потому что Вы можете объяснить разработчикам, что KISS — это хорошо и окно в мир работающего ПО (для тех, кому за за 35 — это я не про группу :))
3. Потому что Вы можете сказать бизнесу, что «прикрутить кнопочку розового цвета» — это плохая идея
4. Потому что Вы можете доказать бизнесу, что «немного дописать программу» займет ну никак не меньше 2 дней
5. Потому что вместо двухчасового рассказа на совещании и показа презентаций «Как мы хорошо заживем» уходите в «подвал к программистам» и через два часа выкатываете работающий продукт
PS Меня достало быть тим-лидом. Я хочу уже снести с компа студию, PL/SQL developer, Eclipse и много прочего хлама!
Где бы найти таких программистов, которые просто делают свою работу? Не пытаются натянуть нейросеть на глобус web-морду к БД, а просто делают быстро и без багов за деньги, которые им платит бизнес
Про локализацию… Все названия, имена, описания — сразу сохраняем в двух языках — локальный и латинский (два поля в БД: NameLoc, NameLat) по минимуму. По максимуму — словарь с языками, ссылки на этот справочник и прочее. Хотя не могу вспомнить систему, где данные (не UI) больше чем на двух языках.
«тут можно и юникод не использовать» — а сейчас точно 2017 год?! Что значит не использовать юникод? Почему? Как?! Типа место экономим? :) Все соврменные средства программирования заточены под юникод, так почему БД не должна его использовать?
Работаю в такой организации :) Как раз пытаются «внедрить Agile» в виде SCRUM. Такие смешные… Во-первых, конечной цели нет — т.е. цели такие:
— сделать все дешевле
— четко знать, какой разработчик что делает, чтобы все были при деле
— ну и потому что Греф сказал, что надо быть Agile…
А так — все как написано — четкое разделение труда, кросс-функциональность встречается в штыки, еще больше наваливание работы, и прочее.
Усилитель не просто усилитель, а усилитель мощности. По-хорошему к нему надо купить предварительный усилитель, чтобы хотя бы громкость регулировать нормально и подключить несколько источников. К Вашему в пару должен подойти Toshiba SY-335 (сугубо по вшнему виду — так то любой конечно). И телефон к хорошему усилителю не надо цеплять :)
Ну почему же не работает? Во всех техниках — главное хотеть что-то сделать. Если задача тяготит, или если в технике «Должен, следует, хочу» в должен очень много и ты понимаешь, что «хочу» не наступит никогда. Или что еще хуже — не знаешь, что ответить на вопрос «Что мне следует сделать с учетом долгосрочных целей?» не можешь найти вопрос, потому что целей нет, тогда ничего никогда работать не будешь. А если что-то делаешь с удовольствием (например, залипаешь в «ящик» (fb, vk, youtube), то и техника никакая не нужна — все само делается :)
На лицо явно ошибка человека, разработавшего ТЗ. Почему в процессе работы над fixed-price проектом происходит детализация? Либо люди, которые оценивали работу в X ч-часов не удосужились детализировать требования.
Что делать:
— обсудить с командой, чтобы у всех было видение ситуации,
— обсудить с клиентом вместе с людьми, которые писали ТЗ. Понять, кто же все-таки неправ (вендор или клиент)
— если вендор неправ (обычно так и бывает :)) попробовать закончить проект в сроки и за тот же бюджет. Да, поговорить с руководством, взять дополнительных разработчиков, пожертвовать собственным бонусом. Если это невозможно, объяснить все это клиенту. Да, он может обращаться в суд, но тогда, скорей всего он вообще не увидит проекта, либо получит низкокачественный продукт. По идее такие вещи должен уже решать не конкретный ПМ, а sales или аккаунт-менеджер. Может быть они в баню сходят с клиентом :) Если клиент мелкий и ненужный — то можно и забить на него.
И еще — в договоре fixed-price всегда нужно прописывать штрафные санкции за срыв сроков, но всегда прописывать максимальную сумму штрафа. Например, 1% от суммы за день просрочки, но не более 10%… Тогда деньги (за минусом макс 10%) будут получены.
Все не так :) Поскольку основная цель таких заведений — это прибыль на поточном производстве, то берется самый дешевый кофе, добавляются ароматизаторы, сахар и вуаля — бурда для офисного планктона готова. Зато как на Wall street — все куда-то бегут и у каждого в руках ЭТО… У нас в Москва-Сити постоянно давка за этими стаканчиками и все думают, что этот напиток помогает им быть более собранными, хотя на первый план выходит «чтобы быть как в кино».
Скорей всего, пил «кофейный напиток», который продается в старбаксоподобных заведениях — тогда честь ему и хвала — одной гадости из организма меньше. Ничто не может сравниться с чашечкой эспрессо, приготовленного в кофемашине из итальянских зерен. Ням :)
И в таких классах задач можно «договориться на берегу», просто требования к разработчику и его действиям (или говоря языком статьи нормы входа, деятельности) будут другие (выше) нежели к разрабу, работающего в более комфортных условиях. Меняются приоритеты/требования — короткие спринты/задачи, бьем задачи на элементарные (можно сделать в течение 1-2 дней, когда приоритеты не меняются). Перед началом разработки — поговорить с заказчиком, убедиться, что все понял правильно. Постоянно показывать результат, не изобретать велосипеды, не тупить над проблемой оптимизации сортировки гномиков и пр. Статья правильная и простая как 2х2 — четыре
Мне одному кажется, что прилетел капитан очевидность? Понятно же, что для определения проблем в чем-либо для начала неплохо бы определить понятие нормы или нормальности.
Мозгоправы в большинстве своем в России специализируются на лечении зависимостей, прежде всего алкогольной. Всякие проблемы менеджеров с зарплатой 5000+ они воспринимают исключительно как "с жиру беситесь". Наверное есть хорошие, но где их найти. Да и тратить свое время на сомнительные сеансы не очень хочется — время не бесконечно
Денег 150+ :)
1. Потому что Вы можете заставить работать то, что еще вчера даже не компилилось
2. Потому что Вы можете объяснить разработчикам, что KISS — это хорошо и окно в мир работающего ПО (для тех, кому за за 35 — это я не про группу :))
3. Потому что Вы можете сказать бизнесу, что «прикрутить кнопочку розового цвета» — это плохая идея
4. Потому что Вы можете доказать бизнесу, что «немного дописать программу» займет ну никак не меньше 2 дней
5. Потому что вместо двухчасового рассказа на совещании и показа презентаций «Как мы хорошо заживем» уходите в «подвал к программистам» и через два часа выкатываете работающий продукт
PS Меня достало быть тим-лидом. Я хочу уже снести с компа студию, PL/SQL developer, Eclipse и много прочего хлама!
глобусweb-морду к БД, а просто делают быстро и без багов за деньги, которые им платит бизнес— сделать все дешевле
— четко знать, какой разработчик что делает, чтобы все были при деле
— ну и потому что Греф сказал, что надо быть Agile…
А так — все как написано — четкое разделение труда, кросс-функциональность встречается в штыки, еще больше наваливание работы, и прочее.
Что делать:
— обсудить с командой, чтобы у всех было видение ситуации,
— обсудить с клиентом вместе с людьми, которые писали ТЗ. Понять, кто же все-таки неправ (вендор или клиент)
— если вендор неправ (обычно так и бывает :)) попробовать закончить проект в сроки и за тот же бюджет. Да, поговорить с руководством, взять дополнительных разработчиков, пожертвовать собственным бонусом. Если это невозможно, объяснить все это клиенту. Да, он может обращаться в суд, но тогда, скорей всего он вообще не увидит проекта, либо получит низкокачественный продукт. По идее такие вещи должен уже решать не конкретный ПМ, а sales или аккаунт-менеджер. Может быть они в баню сходят с клиентом :) Если клиент мелкий и ненужный — то можно и забить на него.
И еще — в договоре fixed-price всегда нужно прописывать штрафные санкции за срыв сроков, но всегда прописывать максимальную сумму штрафа. Например, 1% от суммы за день просрочки, но не более 10%… Тогда деньги (за минусом макс 10%) будут получены.