Та же история, практически. Начинал с кассетных станков, потом кассеты для них стали стоить неприлично дорого и я решил перейти на электробритву. Купил топовый браун, а через года полтора примерно узнал, что головку ему надо периодически обновлять — у меня оказался довольно жесткий волос и от того ножи быстро тупятся. К концу второго года бритва вообще пеерстает брить и начинает нещадно драть волосы. А стоит головка аккурат половину стоимости бритвы. Ну то есть никакой экономии в сравнении с кассетными станками.
В итоге плюнул на весь этот жестокий мир и купил обычный Т-станок с гордым названием «Восток», производства КНР. Брил он довольно неплохо, как мне тогда казалось, позволил научиться правильной технике. С лезвиями, правда, у нас все плохо и в доступе из приличных только Рапира. Но после примерно полугода обучения я созрел на заказ божественного Muhle R89 и набора пробных лезвий от нормальных производителей. И теперь мой сад прекрасен. Напрочь забыл я что такое сменные кассеты, сколько они стоят, что такое раздражение на лице (от электробритвы оно было чертовски сильным, а гладкость бритья была прямо скажем никакая).
Чувствую, следующим шагом будет опаска, но, наверное, лет через пять, когда научусь Т-шкой бриться наощупь без порезов :)
Мы недавно проводили изучение архитектуры VIPER и пришли к выводу, что она несколько недоработана. Основная проблема заключается как раз-таки в слое Router. Единственное(?) решение, которое действительно позволит соблюсти все принципы, это отказ от Storyboard (ну или как минимум отказ от Segues). На мой взгляд, это будет шаг назад, т.к. Storyboards и Segues во многих случаях очень удобны и наглядны. У меня есть наработки по вытаскиванию всей логики переходов в отдельный слой (контроллеры все так же ловят сегвеи, но сразу же передают их в Router через Presenter). К сожалению, какого-то адекватного законченного решения пока нет. Так как это наша первая попытка реализации слоистой архитектуры, вся система показалась нам довольно громоздкой и мы не увидели каких-то радикальных преимуществ. Ну и смущает отсутствие каких-то внятных примеров реализации (пара-тройка демо-приложений с одним-двумя экранами не в счет), а также многозначительное молчание со стороны авторов подхода.
Гораздо более удачной оказалась комбинация различных подходов: MVCP, MVVM, SOA. Как только мы отвязались от жесткого следования структуре VIPER, большинство возникших проблем исчезли сами собой.
А можете рассказать, на кого ориентирован ваш сервис? Например, Slack ориентирован на проектные команды, и он лично для меня очень удобен именно в таких мелочах как клавиатурные команды, тематические комнаты и самое главное — интеграция с различными рабочими сервисами. Мы пока только изучаем его возможности для внедрения в качестве рабочего инструмента, соответственно ищем аналоги и вариации. В связи с этим и вопрос, стоит ли рассматривать ваш сервис в таком ключе или, например, интеграций в нем не будет никогда по идейным соображениям?
Все-таки это выглядит несколько странно. Какими бы ни были специфические требования конкретного бизнеса, эти инструменты создавались и развиваются точно такими же бизнесами. И я сильно сомневаюсь, что тот же Atlassian можно упрекнуть в незнании проектной специфики и непонимании требований их клиентов.
Другой вопрос, что ту же Jira нужно затачивать под свои процессы, чтобы работа с ней не доставляла лишней головной боли. Но она даже в стоковом варианте намного лучше excel :)
На мой взгляд, проблема все-таки не в инструменте, а в подходе. Agile методологии хорошо работают, когда правильно реализованы. Даже водопад имеет право на жизнь, если оставить попытки быть гибкими и допускать вольности. Я это понял, когда мы пытались внедрить CCPM. Тоже хотели сделать свою интерпретацию, подтянуть его к своим условиям и т.п. Но в итоге получилась какая-то ерунда. Еще раз вдумчиво ознакомившись с теорией мы пришли к выводу, что методология работает именно в том виде, в каком ее задумал автор. Любые попытки сделать шаг в сторону приведут к фейлу.
В общем, я убежден, что при правильных процессах и полном понимании сути используемой методологии на рынке полно годнейших инструментов, которые без проблем будут работать сразу из коробки.
Да, с этим всем я согласен. У меня не было цели обвинить вас в неумении применять имеющиеся инструменты, я просто описал типичную ситуацию, в которую сам не раз попадал. Мне по наивности казалось, что я просто мало знаю и не до конца во всем разобрался, раз существующие инструменты кажутся мне неполными или неудобными. Хотя, сомнения в существовании и вообще в возможности их реализации меня никогда не покидали :)
Мне вот показалось, что это эдакое изобретение собственного велосипеда. Мой личный опыт говорит о том, что обычно решение «сделать свое, родное» вызвано не отсутствием на рынке подходящих инструментов, а неумением ими пользоваться и нежеланием разбираться.
Я искренне не могу понять зачем надрывать пупок и работать без выходных и праздников вместо того, чтобы просто один раз взять и разобраться досконально с какой-нибудь существующей системой? С той же Jira. Там есть вообще все, только успевай бабки на счет заносить.
Очень часто встречалась в моей практике ситуация (в том числе и с моим участием), когда изначально заточенный, например, под Scrum инструмент отбрасывался как неподходящий только лишь потому, что на самом деле никто из команды понятия не имеет о том как работает Scrum и как им пользоваться. Очень легко, когда что-то не получается, обвинить в этом именно инструмент, а не себя любимого. Мне стоило больших усилий, чтобы заметить эту черту в себе и переломить ее. А многие так и не замечают, так и перебирают десятки рабочих хороших инструментов и в итоге приходят к выводу, что «надо просто написать свое и не париться».
С другой стороны, не могу поспорить с тем, что разработка своего инструмента очень хорошо помогает разобраться со всеми тонкостями выбранных методик и подходов. Но как по мне это довольно дорогой опыт, можно ведь дешевле достичь тех же результатов.
Это довольно просто. Вы считаете, что чтение научных статей — это вклад в будущее. И это действительно так, если эти статьи связаны с вашим основным родом деятельности. Например, если вы физик и читаете статьи по физике. Пусть на данный момент они не несут прямой пользы, но увеличивают ваши знания в той области, которой вы зарабатываете на жизнь. Но если это статьи из другой сферы и не имеют никакого отношения к вашей (химия, например), то тут, увы, никакой пользы не будет.
Если и так сложно определиться (часто это бывает, когда статьи касаются нескольких областей или область достаточно широкая, чтобы свободно делиться на специализации, та же физика), тут на помощь придет целеполагание. Я надеюсь, у вас есть хотя бы представление о своих планах и целях на будущее, как ближайшее, так и отдаленное. Так вот наивысший приоритет и полезность имеют те статьи, которые помогут достичь ближайших целей. Чем дальше цель во времени, тем ниже ценность информации, которая поможет в ее достижении. Например, я планирую через 5 лет начать активную инвестиционную деятельность. Очевидно, что без хороших знаний по экономике, финансам и инвестированию заниматься этим бесполезно. И знания не за пять минут добываются, нужно уже сейчас начинать обучаться азам и постепенно углубляться в тематику. Но в то же время, без существенного капитала никакие знания мне не помогут. Так что намного больший приоритет имеют те действия, которые приведут к накоплению первичного капитала. Например, изучение основ бюджетирования и ведения бухгалтерского учета. Ну или вообще изучение профильных статей по моей основной деятельности — это окажет прямое влияние на скорость и качество накопления капитала.
В общем, основная моя идея в том, что необходимы четкие цели с понятными шагами и более-менее четкими датами. Иначе любые действия можно списать на прокрастинацию — что-то делаем, а зачем и какой от этого толк не ясно.
Хорошая статья, хорошая система. Но не могли бы вы немного раскрыть обоснование выбора именно таких инструментов? Очевидно, что на внедрение потребовался не день и не два, это был долгий и трудоемкий процесс. Одно только написание вспомогательных скриптов чего стоит. У меня сразу возник вопрос, а нет ли чего-то подобного, но с более низкими требованиями для запуска? Как минимум, с уже готовым набором скриптов, пусть и не покрывающим 100% необходимого?
Есть интерес (и уже даже необходимость назрела) внедрить такую штуку у нас на производстве, но от беглой оценки масштабов трудозатрат становится немного не по себе. Или я преувеличиваю?
А есть что-то более добротное? Я немного занимался в свое время электроникой — работал разработчиком телеком-оборудования. С тех пор много лет прошло, но руки иногда тянутся к «железу», хочется вспомнить былое. Тогда мы использовали OrCAD и PiCAD, но они под винду. И на тот момент казались мне чудо как хороши, хотя старшие товарищи говорили, что жутко глючные и неудобные, но лучше ничего в условно-бесплатном доступе не нашлось. Сейчас я уже давно и прочно сижу на Mac OS и беглое гугление никаких результатов не дало. Такое ощущение, что на Mac OS сидят одни фотографы и музыканты — только для этих профессий есть неисчерпаемые тонны софта разного уровня качества. Для железячников, похоже, ничего нет, увы.
У меня только один вопрос: зачем?
Нет, идея и подход очень интересные, довольно оригинальные. Мне всегда нравится, когда хорошо известным инструментам из одной области находится достойное применение в совершенно другой. Если только это применение приносит значительное улучшение и решает конкретную проблему, которую традиционные инструменты решить не могут. Например, проблему отсутствия приличного редактора электронных схем, скажем, под Mac (говорю наугад, я не очень в теме). А какую проблему решает использование 3д-редактора для рисования несложных электронных схем?
P.s.: на голосовалку ответил «да», очень интересно почитать развитие истории.
Заказчик очень рад подписывать такой документ, т.к. он дает ему четкое понимание сроков и ответственных. Заказчик не меньше нашего заинтересован в реализации проекта точно в срок, но зачастую не имеет необходимых инструментов для контроля за процессом. Этот документ является одним из таких инструментов, которые полезны и нам и заказчику.
Но ведь на самом деле причина всех описанных проблем не в наличии дедлайна. Если бы не существовало ограничения срока, проблемы были бы все те же самые, но дополнительно еще продукт никогда бы не зарелизился. Проблема в управлении проектом и в подходах к разработке, но никак не в наличии дедлайна.
Не всегда так. В специфике нашего целевого клиента это практически никогда не так. Сроки критически важны, на дату релиза назначено очень много событий, вовлечено много людей и компаний. Это ситуация, когда нужно все или ничего.
Это очень полезный документ, в котором зафиксированы все сроки поставок, команда проекта, ответственные лица и общая информация. Подписан директорами обеих сторон и не подлежит правке.
Любой целевой клиент. У нас это выведено в разряд корпоративной этики: мы небольшое агентство, где все всегда в курсе последних новостей от клиента. ТЗ рождается внутри проектной команды, устав проекта доносится до всей команды на уставном собрании, мы даже проводим визуальное знакомство команды с клиентом, как минимум общее фото, а если возможно, то совместный звонок по скайпу. Это с первых дней очень сильно сближает нас с клиентом и всегда приносит положительные результаты.
Особо подчеркну, что мы работаем только с целевыми клиентами. Т.е. с такими, которые вписываются в наши критерии отбора и только когда нам интересны их проекты. За редкими исключениями можем взяться за не очень интересный проект ради стратегических целей, но в последнее время и без этих реверансов хватает работы.
В итоге плюнул на весь этот жестокий мир и купил обычный Т-станок с гордым названием «Восток», производства КНР. Брил он довольно неплохо, как мне тогда казалось, позволил научиться правильной технике. С лезвиями, правда, у нас все плохо и в доступе из приличных только Рапира. Но после примерно полугода обучения я созрел на заказ божественного Muhle R89 и набора пробных лезвий от нормальных производителей. И теперь мой сад прекрасен. Напрочь забыл я что такое сменные кассеты, сколько они стоят, что такое раздражение на лице (от электробритвы оно было чертовски сильным, а гладкость бритья была прямо скажем никакая).
Чувствую, следующим шагом будет опаска, но, наверное, лет через пять, когда научусь Т-шкой бриться наощупь без порезов :)
Гораздо более удачной оказалась комбинация различных подходов: MVCP, MVVM, SOA. Как только мы отвязались от жесткого следования структуре VIPER, большинство возникших проблем исчезли сами собой.
Другой вопрос, что ту же Jira нужно затачивать под свои процессы, чтобы работа с ней не доставляла лишней головной боли. Но она даже в стоковом варианте намного лучше excel :)
На мой взгляд, проблема все-таки не в инструменте, а в подходе. Agile методологии хорошо работают, когда правильно реализованы. Даже водопад имеет право на жизнь, если оставить попытки быть гибкими и допускать вольности. Я это понял, когда мы пытались внедрить CCPM. Тоже хотели сделать свою интерпретацию, подтянуть его к своим условиям и т.п. Но в итоге получилась какая-то ерунда. Еще раз вдумчиво ознакомившись с теорией мы пришли к выводу, что методология работает именно в том виде, в каком ее задумал автор. Любые попытки сделать шаг в сторону приведут к фейлу.
В общем, я убежден, что при правильных процессах и полном понимании сути используемой методологии на рынке полно годнейших инструментов, которые без проблем будут работать сразу из коробки.
Я искренне не могу понять зачем надрывать пупок и работать без выходных и праздников вместо того, чтобы просто один раз взять и разобраться досконально с какой-нибудь существующей системой? С той же Jira. Там есть вообще все, только успевай бабки на счет заносить.
Очень часто встречалась в моей практике ситуация (в том числе и с моим участием), когда изначально заточенный, например, под Scrum инструмент отбрасывался как неподходящий только лишь потому, что на самом деле никто из команды понятия не имеет о том как работает Scrum и как им пользоваться. Очень легко, когда что-то не получается, обвинить в этом именно инструмент, а не себя любимого. Мне стоило больших усилий, чтобы заметить эту черту в себе и переломить ее. А многие так и не замечают, так и перебирают десятки рабочих хороших инструментов и в итоге приходят к выводу, что «надо просто написать свое и не париться».
С другой стороны, не могу поспорить с тем, что разработка своего инструмента очень хорошо помогает разобраться со всеми тонкостями выбранных методик и подходов. Но как по мне это довольно дорогой опыт, можно ведь дешевле достичь тех же результатов.
Если и так сложно определиться (часто это бывает, когда статьи касаются нескольких областей или область достаточно широкая, чтобы свободно делиться на специализации, та же физика), тут на помощь придет целеполагание. Я надеюсь, у вас есть хотя бы представление о своих планах и целях на будущее, как ближайшее, так и отдаленное. Так вот наивысший приоритет и полезность имеют те статьи, которые помогут достичь ближайших целей. Чем дальше цель во времени, тем ниже ценность информации, которая поможет в ее достижении. Например, я планирую через 5 лет начать активную инвестиционную деятельность. Очевидно, что без хороших знаний по экономике, финансам и инвестированию заниматься этим бесполезно. И знания не за пять минут добываются, нужно уже сейчас начинать обучаться азам и постепенно углубляться в тематику. Но в то же время, без существенного капитала никакие знания мне не помогут. Так что намного больший приоритет имеют те действия, которые приведут к накоплению первичного капитала. Например, изучение основ бюджетирования и ведения бухгалтерского учета. Ну или вообще изучение профильных статей по моей основной деятельности — это окажет прямое влияние на скорость и качество накопления капитала.
В общем, основная моя идея в том, что необходимы четкие цели с понятными шагами и более-менее четкими датами. Иначе любые действия можно списать на прокрастинацию — что-то делаем, а зачем и какой от этого толк не ясно.
Есть интерес (и уже даже необходимость назрела) внедрить такую штуку у нас на производстве, но от беглой оценки масштабов трудозатрат становится немного не по себе. Или я преувеличиваю?
Нет, идея и подход очень интересные, довольно оригинальные. Мне всегда нравится, когда хорошо известным инструментам из одной области находится достойное применение в совершенно другой. Если только это применение приносит значительное улучшение и решает конкретную проблему, которую традиционные инструменты решить не могут. Например, проблему отсутствия приличного редактора электронных схем, скажем, под Mac (говорю наугад, я не очень в теме). А какую проблему решает использование 3д-редактора для рисования несложных электронных схем?
P.s.: на голосовалку ответил «да», очень интересно почитать развитие истории.
Особо подчеркну, что мы работаем только с целевыми клиентами. Т.е. с такими, которые вписываются в наши критерии отбора и только когда нам интересны их проекты. За редкими исключениями можем взяться за не очень интересный проект ради стратегических целей, но в последнее время и без этих реверансов хватает работы.