タグ

プロジェクトと考え方に関するindicationのブックマーク (10)

  • だれかの進捗をうまく把握できないときのフレーズ集 - Qiita

    ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか? → 進行中です/〜をやっています なにか問題はありますか? → とくにないです 〜までに終わりそうですか? → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ

    だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
    indication
    indication 2022/11/09
    とても良い質問集。
  • なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

    はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

    なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
    indication
    indication 2021/11/01
    三乗根って、どうやって電卓で計算するん🤔
  • 不安とストレスから解放される見積りとスケジュール方法

    はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事プロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。 また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。 稿では、プロジェクトにおける不安とはなんだろうか?を考え、できる限り不安を最小化させるということを主眼に置いたスケジュ

    不安とストレスから解放される見積りとスケジュール方法
    indication
    indication 2020/09/25
    不確実性を取り入れたいが、弊社は工数ベースなので入れると詰まれるから、つらい。~が不確実なので、という話をすると見積段階で潰してくるので、見積を断る勇気が欲しい
  • 成長できる機会は無い、技術者はもうプロマネを目指すな

    この「極言暴論」の記事はIT業界技術者の間でちょくちょく物議を醸す。「暴論」とうたっているわけだし、人月商売のIT業界の悪弊やユーザー企業のIT部門の駄目さ加減などを徹底的にこきおろしているから、当たり前といえば当たり前だ。 記事や私に対する大概の批判は感情的なものなので、「おいおい、もっと冷静になって現状をよく見たほうがいいぞ」と思いつつ、スルーすることにしている。ただ、あるテーマに関しては理性的な批判も多く、「この違いは何なのか」とずっと考えていた。 そのテーマとは「プロジェクトマネジャーは誰が担うのか」である。私の答えは随分前から決まっている。「プロマネは技術者の仕事ではない」。そう言い切っていた。技術者が担っても構わないが、SEやプログラマーといった技術者カテゴリーの仕事とは全くの別物なのだ。 だってそうだろう。プロマネはマネジメントが仕事なのだから当たり前である。技術者だけでな

    成長できる機会は無い、技術者はもうプロマネを目指すな
    indication
    indication 2019/06/03
    数億規模の案件MGRと一緒に帰ったときに、一人で10歩ではなく全員で1歩をやってる、と聞いた。今思うと技術的プロセスとは全く異なる。
  • プロジェクト管理のエモいはなし - Qiita

    前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日IT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そういった事情もあり、プロジェクト管理からは距離を置くようにしていたのですが、最近またプロジェクトマネジメントについて考える機会が多くなったので、この辺で昔話をしてみようと思います。 他山の石としてワカモノの役に立てば。 前提として ガチガチのウォーターフォー

    プロジェクト管理のエモいはなし - Qiita
    indication
    indication 2017/06/21
    数億規模のプロジェクトリーダーは凄かった。プレッシャーも相当なのに、ちゃんと終わる日を教えてくれと一人一人に聞いて回ってた。
  • 指示が意図した通りにメンバーに伝わったら、むしろ驚け

    この連載では、先が見えないプロジェクトを「暗闇プロジェクト」を担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。 前回(部下はマネジャーのようには決して考えない、期待しても無意味)から、「暗闇」でのメンバーマネジメントを取り上げている。今回も、二つのセオリーを紹介したい。 セオリー1 時には指示をあいまいにするのも手 マネジャーのD氏はイラついていた。中途で入社したU氏に対してである。 U氏の学歴や職歴は申し分ない。発言や質問の内容から、地頭の良さがうかがえる。問題は、言われた仕事しかしないことだ。 「次の打ち合わせのための資料を作成してくれないか」などと明確に指示を出すと、U氏は確かに言われたことはする。ただ、それだけである。「これはどうなった?」と付随する作業について尋ねると、まず間違いなく「指示になかったので、やっていません」と答える。 「お前はロボットか?」

    指示が意図した通りにメンバーに伝わったら、むしろ驚け
    indication
    indication 2016/07/06
    通訳をはさむのが効果的なパターン…
  • システム屋としてのいろはをIBMに教えてもらった僕が今のIBMに思うこと - novtan別館

    思えば、新人の頃の僕はIBMのプロジェクトと共にあった。当時、色んな意味でいい加減だった自社(今はそうでもない)ではなく、現場のIBMが僕を育ててくれた。プロジェクト管理の仕方、見積の仕方、顧客との交渉の仕方、そしてもちろん、技術を。 純粋に技術という点ではむしろ自社の先輩や自分自身の勉強がほとんどの部分もあったと思う。でも、サーバーとの付き合い方を色んな意味で学ばせてくれたのはやはりサーバーからアプリまで全部自分たちでやるというプロジェクトであったからだろう。 日IBMの最近の営業施策を見るにつけ、日ならではのハイコンテクストな関係を軽視しているように感じます。何十年と続いてきた手帳やテーブル・カレンダーの廃止、ユーザー組織やパートナー組織を支援する人員や予算の削減などは、確かに売上に直結するものではありません。しかし、こういう濃密な人のつながりやブランド価値を浸透させるための取り組

    システム屋としてのいろはをIBMに教えてもらった僕が今のIBMに思うこと - novtan別館
    indication
    indication 2014/04/09
    すこしだけ心にとめておこう
  • オープンソースプロジェクトに参加するにあたっての心得10ヶ条 - YAMDAS現更新履歴

    A guide to participating in an open source project | opensource.com 著者はオープンソース・クラウドプラットフォーム・ベンダの WSO2 の人らしいが、彼が説くオープンソースプロジェクトに参加を始めるにあたっての心得10ヶ条は以下の通り。 解決すべき真の問題、ビジネスニーズ、何らかの商業ドリブンの動機を持て。 プロジェクトの目標を理解し、自分の貢献がそれに沿っていることを確かめる。 十分な機能を実装する完全なパッチを投稿せよ。何かしらテスト情報やドキュメンテーションも含めて。 自分が貢献しているプロジェクトのルールに従って行動する。 謙虚たれ。決して自分の名前を貢献者リストに自分で追加してはならない。プロジェクトリーダがあなたの仕事を評価すれば、その人がすべきことなのだから。 期待度は低く。拒絶を受け入れることを学べ。 辛抱

    オープンソースプロジェクトに参加するにあたっての心得10ヶ条 - YAMDAS現更新履歴
  • 属人性排除の功罪 - 人と技術のマッシュアップ

    ソフトウェアの開発においては長年、属人性の排除が叫ばれてきました。今回は属人性の功罪について考えてみます。 属人性の排除の目的 定められた成果物を作成することにより、他の人にも理解しやすいようにすること 誰が担当しても一定の品質を保つことを可能にすること 成果物が一定の形を為しているため工程管理しやすい だいたいこんな感じだと思います。私もメーカ時代には規約を作成したり、成果物の設計をしたりしていました。まぁその時は当たり前に良いことだと思って取り組んでいたわけですが・・・ 属人性の排除によるデメリット 製品品質としては安定するけれども、一方でコード品質は下がる プログラマとしての価値は一定となり、個人の生産性が無視される プログラマのスキルが低レベルで一定となり、優秀な人材が辞めていく どういうことかというと、こういった属人性の排除を行うには、規約を決めたりするなどの制約を課すことになり

    属人性排除の功罪 - 人と技術のマッシュアップ
    indication
    indication 2012/05/15
    隠しコマンドで作成者一覧が出るって、結構品質に貢献しそう
  • 終わるSIerの底辺を見てきた - ミッションたぶんPossible

    ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この

    終わるSIerの底辺を見てきた - ミッションたぶんPossible
  • 1