И да и нет. С одной стороны — соглашусь, фиктивные мероприятия вряд ли кому нужны. С другой стороны — ИТ-шники тоже люди, им тоже хочется подтверждения самооценки, значимости и т.д. Благодарности от тимлидера часто не достаточно.
Я бы сказал, надо избегать изоляции отделов вообще и ИТ в частности. Все должны принимать участие если не в управлении но в жизни предприятия. Кроме мотивации это часто получает еще и позитивный коммерческий эффект.
Хочется увидеть проверку того, что saveData() запишет файл именно нужного формата. Что, в частности, перевод строки там будет именно \r\n а не \n.
Ценность юнит-тестов, как я понимаю, еще и в том, что они ограждают от необдуманного изменения поведения функций. То, что они возвращают «все прошло хорошо» — конечно интересно, но это вершина айсберга.
Второе название топика — «Как давать формальные ответы на формальные вопросы, ответы на которые все-равно никого не интересуют»
— почему вы хотите работать у нас?
Если вы не гугл с яндексом, то я еще не уверен, что хочу именно у вас. Я тоже пришел на вас посмотреть сначала.
— Чем вы можете быть нам полезны?
Мои способности указаны в резюме, о ваших потребностях я понятия не имею.
— Кем вы видите себя через 5 (10) лет?
Я может недальновидный идиот, но неужели люди реально строят планы на 10 лет? Это скорее не планы а фантазии а-ля «хочу выйти за принца и жить на собственном острове».
Лично я каждый год удивляюсь и говорю себе «надо же год назад я бы и не подумал, что так будет».
Спросите лучше просто — чем нравится заниматься а чем нет.
— Каковы ваши сильные/слабые стороны?
Какой вообще смысл на собеседовании рассказывать о слабых сторонах? Я же себя продать пришел, зачем я буду рассказывать, что часто опаздываю по утрам например? ))
Ну и ваши слова практически всегда будут переданы руководителю отдела, куда вы хотите устроиться
Если руководитель будущего моего отдела не присутствует на собеседовании, это как минимум странно.
Это да. Хоть к срокам не особо относится, а к процессу постановки задачи.
Я это формулирую так:
Не спрашивайте, что хочет заказчик, спросите что у него за проблема, которую он хочет решить. Или какие мысли его привели к вам (мотивация иными словами)
Пока будут попадаться заказчики, которые не понимая реально что им нужно, не понимая отдельных аспектов в разработке программного продукта, требуют самых коротких сроков — придется делать оценки, которые будут далеки от реалистичных.
Т.е. наоборот — наплевать, что опыт, оценки и чутье подсказывает, если заказчик требует «быстро», надо пообещать ему «быстро»
Т.е. вы утверждаете, что оценку проекта нужно делать исходя из пожеланий заказчика? ))
Даже если программист квалифицированный, задача поставлена ясно и понятно и не меняется — грамотно оценить ее можно только если она, скажем так, стандартна и тривиальна. Т.е. не содержит особого элемента новизны или исследований.
Оценка проектов, включающих исследования — самое неблагодарное занятие. Это вам любой менеджер скажет.
Но современный мир таков, что одинаковые и рутинные проекты уже никто не делает. Если задача уже решена — значит ее решение можно купить.
Вывод — большинство проектов плохо предсказуемы и все.
Если программист говорит «день» — это значит, что «может и два». Но плюс-минус день это не страшно да? Но если он говорит неделя/месяц/квартал/год — это тоже может значить «а может и 2».
Вывод — планировать больше чем на месяц почти бесполезно. Люди, описавшие agile, не зря там месяц в основном используют.
Ну с другой стороны, переоценка скорости разработки — одна из самых частых ошибок. Както мне рассказывали, что какя-то из версий Майкрософт-ворд разрабатывалась 3 года вместо 1.5 только из-за того, что план был построен на 1 год.
Проект не может сделаться быстрее чем он должен делаться, 9 женщин не родят ребенка за месяц.
Проблема в другом — сейчас и так все умножают цифры, полученные от девелопера, на 2 или 3. Но это все-равно не помогает.
Я считаю вообще утопичным строить длинные планы. Вся история девелопмента говорит о том, что сроки чаще срываются. Не говорит ли это о том, что многие вещи вообще нереально грамотно спланировать по времени?
Так что, я бы ваш вопрос перефразировал в 2 других:
1. Как сделать так, чтобы проект разрабатывался максимально эффективно
2. Как делать реалистичную оценку
«Ай-ай-ай! Проект делается в 2 раза дольше запланированного» — это и есть та самая эпичная ощибка менеджера. Проекту как-бы наплевать на то что вы о нем думаете ))
А какже насчет:
— Решили по середние пути купить велосипеды (они же быстрее!!). Потратили кучу денег и день на поиск и подготовку. Но оказалось, что дальше надо идти по песку и велосипеды медленнее чем пешком.
— Решили взять попутчика, он очень быстро ходит и вообще спортсмен. Но оказалось, что он не знает дороги, поэтому помтоянно убегал вперед кудато нетуда, приходилось его искать.
Ну и эпическое:
— Ждущие нас друзься выслали выртолет, чтобы быть в курсе событий. Он постоянно кружил над башкой, мешал идти. А еще спускался каждый час и пытался выяснить, почему так медленно идем. И рассказывал, что чем позже мы придем тем меньше нам достанется за ужином, думая, что это нас както замотивирует бежать бегом.
Я бы сказал, надо избегать изоляции отделов вообще и ИТ в частности. Все должны принимать участие если не в управлении но в жизни предприятия. Кроме мотивации это часто получает еще и позитивный коммерческий эффект.
Ценность юнит-тестов, как я понимаю, еще и в том, что они ограждают от необдуманного изменения поведения функций. То, что они возвращают «все прошло хорошо» — конечно интересно, но это вершина айсберга.
Иначе я не вижу обоснования такому фильтру. Часто хорошие технические специалисты как раз не слишком адекватны.
— почему вы хотите работать у нас?
Если вы не гугл с яндексом, то я еще не уверен, что хочу именно у вас. Я тоже пришел на вас посмотреть сначала.
— Чем вы можете быть нам полезны?
Мои способности указаны в резюме, о ваших потребностях я понятия не имею.
— Кем вы видите себя через 5 (10) лет?
Я может недальновидный идиот, но неужели люди реально строят планы на 10 лет? Это скорее не планы а фантазии а-ля «хочу выйти за принца и жить на собственном острове».
Лично я каждый год удивляюсь и говорю себе «надо же год назад я бы и не подумал, что так будет».
Спросите лучше просто — чем нравится заниматься а чем нет.
— Каковы ваши сильные/слабые стороны?
Какой вообще смысл на собеседовании рассказывать о слабых сторонах? Я же себя продать пришел, зачем я буду рассказывать, что часто опаздываю по утрам например? ))
Ну и ваши слова практически всегда будут переданы руководителю отдела, куда вы хотите устроиться
Если руководитель будущего моего отдела не присутствует на собеседовании, это как минимум странно.
Я это формулирую так:
Не спрашивайте, что хочет заказчик, спросите что у него за проблема, которую он хочет решить. Или какие мысли его привели к вам (мотивация иными словами)
Не проект впихивают в сроки, а сроки — это оценка проекта.
Сложность проекта — величина математическая, для нее не существует понятия заказчика. Только постановка задачи, ресурсы и риски.
Срок, который вы пишете в договоре, это не оценка проекта, это условия договора.
Давайте не путать тему топика ))
Ааа!!! В сроки этапа не укладываемся, а завтра нужно показать заказчику. Слепи что-нибудь временное, потом переделаем.
Именно разработка «временных» решений и отхождение от первоначальных требований в угоду срокам — увеличивает суммарный срок.
Пока будут попадаться заказчики, которые не понимая реально что им нужно, не понимая отдельных аспектов в разработке программного продукта, требуют самых коротких сроков — придется делать оценки, которые будут далеки от реалистичных.
Т.е. наоборот — наплевать, что опыт, оценки и чутье подсказывает, если заказчик требует «быстро», надо пообещать ему «быстро»
Растягивание проекта — это проблема для пессимистичной оценки.
Ибо начинаются нервотрепки, трах мозга, пренебрежение качеством, разработка ненужного функционала и т.д.
Даже если программист квалифицированный, задача поставлена ясно и понятно и не меняется — грамотно оценить ее можно только если она, скажем так, стандартна и тривиальна. Т.е. не содержит особого элемента новизны или исследований.
Оценка проектов, включающих исследования — самое неблагодарное занятие. Это вам любой менеджер скажет.
Но современный мир таков, что одинаковые и рутинные проекты уже никто не делает. Если задача уже решена — значит ее решение можно купить.
Вывод — большинство проектов плохо предсказуемы и все.
Если программист говорит «день» — это значит, что «может и два». Но плюс-минус день это не страшно да? Но если он говорит неделя/месяц/квартал/год — это тоже может значить «а может и 2».
Вывод — планировать больше чем на месяц почти бесполезно. Люди, описавшие agile, не зря там месяц в основном используют.
Проект не может сделаться быстрее чем он должен делаться, 9 женщин не родят ребенка за месяц.
Проблема в другом — сейчас и так все умножают цифры, полученные от девелопера, на 2 или 3. Но это все-равно не помогает.
Я считаю вообще утопичным строить длинные планы. Вся история девелопмента говорит о том, что сроки чаще срываются. Не говорит ли это о том, что многие вещи вообще нереально грамотно спланировать по времени?
Вот тут очень хороший топик-притча habrahabr.ru/blogs/pm/137519/
Так что, я бы ваш вопрос перефразировал в 2 других:
1. Как сделать так, чтобы проект разрабатывался максимально эффективно
2. Как делать реалистичную оценку
«Ай-ай-ай! Проект делается в 2 раза дольше запланированного» — это и есть та самая эпичная ощибка менеджера. Проекту как-бы наплевать на то что вы о нем думаете ))
А деанонимизация — чего тут придумывать то, есть же gosuslugi.ru, зарегался да голосуй сколько хочешь.
А какже насчет:
— Решили по середние пути купить велосипеды (они же быстрее!!). Потратили кучу денег и день на поиск и подготовку. Но оказалось, что дальше надо идти по песку и велосипеды медленнее чем пешком.
— Решили взять попутчика, он очень быстро ходит и вообще спортсмен. Но оказалось, что он не знает дороги, поэтому помтоянно убегал вперед кудато нетуда, приходилось его искать.
Ну и эпическое:
— Ждущие нас друзься выслали выртолет, чтобы быть в курсе событий. Он постоянно кружил над башкой, мешал идти. А еще спускался каждый час и пытался выяснить, почему так медленно идем. И рассказывал, что чем позже мы придем тем меньше нам достанется за ужином, думая, что это нас както замотивирует бежать бегом.